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