If I'm understanding it correctly, there's an interesting quality to this bundling together of all the behaviour related to a given option. The subcomponent configuration for both UI Options and UI Enhancer is identical, and can be shared. It contains all the information required to setup components for editing the options as well as components for actually executing the option.
Thanks so much for the summary. This is going to be an awesome refactoring for our flagship component. Colin On 2011-05-13, at 5:36 PM, Michelle D'Souza wrote: > To accomplish this UI Options will be changed to have a subcomponent for > every setting. These subcomponents will be composed of everything relating to > a particular setting including: a selector, a proto-tree, a model and the > strategy for transforming the page based on the setting state. Concretely, > this will require building many small components that can be composed into > these settings. We will create renderer components for each way a setting can > be set - for example a range, a boolean or a select. We would also create > small components for each transformation strategy. > > UI Options itself will become a shell containing subcomponents that are a > composition of a renderer component and a transformation strategy. All UI > Options would do is compose proto-trees from the subcomponents and render the > UI. Eventually, even this work will be in the framework and UI Options will > do nothing but hold settings. Similarly, UI Enhancer would defer to these > subcomponents when transforming the page. The only real work that would be > left in UI Enhancer is any global clean up that needs to be done before > performing the transformation. --- Colin Clark Lead Software Architect, Inclusive Design Research Centre, OCAD University http://inclusivedesign.ca _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
