Thanks Antranig, It was indeed included in that list.
Yura On 2013-01-18, at 3:28 PM, Antranig Basman <[email protected]> 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 <[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 >> > > _______________________________________________________ > 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
