UIO Architecture

[Zenevich, Yura]

Hi,

I have created a UIO Options iteration page that is for now very barebones:

http://wiki.fluidproject.org/display/fluid/User+Interface+Options+Iteration+Planning 

It contains a list of JIRA tickets that describe the actual work that we are planning to tackle first. Let me know if you see anything missing or in case I am describing something incorrectly (I tried to write those JIRA's up based on the notes that were sent previously in this thread :) ).

Regards,

Yura

On 2013-01-16, at 10:24 AM, Yura Zenevich <yzenevich at ocad.ca> wrote:

> Here's are notes from yesterdays meeting:
> 
> http://openetherpad.org/er3uvaXL1x
> 
> Yura
> 
> On 2013-01-11, at 3:55 PM, "Zenevich, Yura" <yzenevich at ocadu.ca> wrote:
> 
>> 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)).
>> 
>> Regards,
>> 
>> Yura
>> _______________________________________________________
>> fluid-work mailing list - fluid-work at fluidproject.org
>> To unsubscribe, change settings or access archives,
>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>