2017-01-10 Meeting notes

Owned by Josh Zamor
Last updated: Jan 10, 2017Version comment

Date

7am PST

https://www.uberconference.com/villagereach-isg

Optional dial in:
Dial in: 213-493-0531
PIN: 74762

Attendees

Goals

  • Make decisions on UI extensibility:  how it works, how it's communicated, etc

Discussion items


Previous meeting:  Dec 20, 2016

TimeItemWhoNotes
5mStartJosh

go over agenda and wait for folks to join

55mUI ExtensibilityNick 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.


OpenLMIS: the global initiative for powerful LMIS software