UIO Architecture

[Zenevich, Yura]

Thanks Antranig,

It was indeed included in that list.

Yura

On 2013-01-18, at 3:28 PM, Antranig Basman <antranig.basman at colorado.edu>
 wrote:

> 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
>> 
> 
> _______________________________________________________
> 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