UIO Architecture

Zenevich, Yura yzenevich at ocadu.ca
Fri Jan 11 20:55:02 UTC 2013

Hi everyone,

Today we continued talking about the challenges that we need to address during the upcoming
architecture work for UI Options component. Antranig provided an excellent summary of what
our action items should be. So here it is:

1) Store problem: Store.js depends on the exact concrete panels that are in UIO and cannot
have new default values for new options contributed in.

2) Options distribution problem: Pointy configuration is required for all new panels (e.g. video
panel) and "new" panels can not be first class in the same way as existing ones (cannot have
their options promoted to top level in the options structure)

3) A BUG: The component behaves incorrectly with a change in defaults. ONLY the changes
users make to default options should be saved in the store - in the following sequence:
	a) User changes option a
	b) Default changes for option b
	c) Next time user loads the component, they get the old default for option b even though
	they never requested it

4) In general, we need a "UIOptions builder" that can fabricate a UIO which shows any
particular set of options/panels in a model-driven way - this should not require new code for
each configuration

5) Increased understanding of SCHEMA - when new options appear of previously familiar
types, we shouldn't have to do extra work in order to figure out how to render the UI for them -
this will also feed into generation of "guards" (in the ChangeApplier sense) performing
model-directed validation to ensure that out-of-range values are not stored. The
"linearRangeGuard" currently living in the VideoPlayer integration is an example of this

Some of these points look like they can be investigated independently ((3) and (5)), yet it
seems like the rest of them are still a little too high level and should serve as a sort of umbrella
tasks. In order for us to come up with concrete sizeable chunks to start working on we still
need to take a closer look at the current architecture and see/document in JIRA what needs
to be done to address them (in particular (2) and (4)).



More information about the fluid-work mailing list