2017-01-10 Meeting notes
Date
7am PST
Meeting Link
https://www.uberconference.com/villagereach-isg
Optional dial in:
Dial in: 213-493-0531
PIN: 74762
Attendees
- Elias Muluneh
- Paweł Gesek
- Sebastian Brudziński
- Nikodem Graczewski (Unlicensed)
- Pengfei Cui (Deactivated)
- Nick Reid (Deactivated)
- Brandon Bowersox-Johnson
- Darius Jazayeri (Unlicensed)
Goals
- Make decisions on UI extensibility: how it works, how it's communicated, etc
Discussion items
Previous meeting: Dec 20, 2016
| Time | Item | Who | Notes |
|---|---|---|---|
| 5m | Start | Josh | go over agenda and wait for folks to join |
| 55m | UI Extensibility | Nick Reid (Deactivated) | Part 3 on UI Requisition Splitting - UI Extensions |
Notes
We're following Nick in this document:
Requisition Splitting - UI Extensions
Option A is "clearer" / more explicit than B in what can be extended. That is that option B makes no declarations about what should be extended where, it simply allows for anything to be added / overloaded. In practice if a new requisition status is added to the product / back-end, then option A would be used to declare that the template for the action bar (has the user action buttons for requisition) is extendable and new buttons could be added to that action bar template without overriding the template itself (which is what option B gives us). If the reference UI moves along and unrelated buttons are added, then no new work should be needed on the part of the extension to accommodate both sets of changes.
How difficult for an implementation to use?
The workflow is add to the config file and start adding your screens / markup.
It doesn't seem that complicated - though the further down the rabbit hole it goes (having lots of templates each for very small portions of the screen), the less manageable this gets.
Option A can use unique IDs for each template. Ideally these should be prefixed with the name of the repository / UI module to avoid collisions.
Business logic is added in option A by injecting a controller.
The community process of option A feels very similar to extension pts and modules for the Services. If an implementer wanted to keep following the Reference UI, but also make changes, then they'd create a template with an Option A "extension point", submit a pull request to the community, and as soon as that was merged everyone in the community, including the implementer, could take advantage of that extension mechanism.
Most interest seems to be leaning toward option A. However there's very reasonable concern about timing (for 3.0 esp), complexity, etc. In choosing option A, we're declaring that this is the extension mechanism (along with all the existing pieces around build process, CSS, etc) for the modular UI, however we need to be careful in how we time it and how far we go so that we're not creating unneeded complexity. We also need to consider the burden to the implementer - the simpler the better. That said building Option A is the decision, though only the core pieces will be done for 3.0.
After meeting thoughts (audio trouble):
In the long term - would it be possible to package extensions? Would it be possible to compose installations/implementations from extensions that come from multiple vendors?(is this desired?) How complicated or easy will that be with the choices we make? My suggestion would be to keep these thoughts, not necessarily answer them.
Action items
- Nick Reid (Deactivated) Add tickets for implementing option A in 3.0
- Nick Reid (Deactivated) to discuss documenting option A in 3.0 in next call (Jan 24)
OpenLMIS: the global initiative for powerful LMIS software