UIO Architecture

[Antranig Basman]

This JIRA should also be part of the collection since it describes the Store bug that is on our work list:

http://issues.fluidproject.org/browse/FLUID-4686

Perhaps an umbrella JIRA for the whole collection would be useful?

Cheers,
A

On 18/01/2013 13:23, Zenevich, Yura wrote:
> 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
>>
>
> _______________________________________________________
> 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
>