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
