Page Comparison

...

Notes

UI Extension Maintainability

Developer Experience

• Branding changes
• Adding new functionality
• Changing existing functionality

Integrating Updates

• Unit test strategy changed
• Maintain JS patches for "forked" files
  • Change to AngularJS Decorator
  • Can these files be made smaller?
• Maintain markup changes

Improving UI Experience

• Extension Directive

...

Malawi UI Development Notes

From Weronika Ciecierska (Unlicensed) (added notes from Nick Reid (Deactivated) in italics, he also reformatted the notes slightly ;-)

...

At the beginning it was quite easy task to do, but merging this month's release was a little bit more complicated. Example: As mentioned in (1), we changed the "isReadOnly" method from the product grid. In the latest release the core team refactored this method (functionality was still the same) - so when merging those changes, I remembered that I changed this method in the forked file and merged it correctly, but if I weren't working on it before, I probably wouldn't notice this small change and just copy the new, refactored function to the forked file (on the other hand, that would make our overwritten unit tests fail and make developer realize that this functionality was changed in the Malawi implementation).

...

There is no git history for the forked files - so we don't know which files are new and which are copied from the core repository. AdditionalyAdditionally, we don't know what was changed in the files copied from the core - once I had to use online files comparator to determine what was different in the forked file.

The easiest solutin solution for this is just add files from the core with two commits: first commit with the original file and THEN changes made in this file for the Malawi implementation in the next commit. Maybe it is possible to get git history of the files when we move Malawi repos to the different organisationorganization? This would probably be solved by using a second organization on github and forking repositories that are getting "functional changes"

UI Extension Maintainability

• Branding changes
  • Good
  • Currently undocumented — changing in OLMIS-???? by making template where OpenLMIS branding is separate, forkable, repository
• Adding new functionality
  • Pretty good
  • Have yet to see if features can be meaningfully maintained
• Changing existing functionality
  • Malawi implementation was unique because it was inside same github organization
    • it didn't fork larger repos so git could track changes and pull requests
  • File forking was intended for HTML markup changes
    • Pattern borrowed from Django framework

    • Q: Is markup maintenance a reasonable responsibility?

  • Large (important) files, such as RequisitionService, shouldn't be forked
    • Makes meaningless commit
    • Have to merge in changes from original project
    • Overwriting unit tests is a little nuts
    • Are these files too big?
  • AngularJS Decorator
    • Wraps methods of function
    • Can preserve original unit tests and 'changed' unit tests
    • Doesn't have access to internal object functions or state
    • Needs documentation in UI Extension Guide AND working examples

Improving UI Experience

• Extension Directive (ticket is rated 21 story points, without implementing in codebase) — too expensive?

Action items