Hi everyone, Antranig, Cindy, Colin and I just had a meeting to discuss how we will structure UI Options. Our overarching goal with this refactoring is to make it very easy for an implementor to add a new setting to UI Options. Currently, there are several places where an implementor would need to touch code in order to add a setting. Our strategy would change this so that an implementor could add new behaviour through IoC style configuration.
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. This is a fairly large but also straightforward refactoring. We will attempt to do this for 1.4 but will prioritize implementing the new wireframes over the refactoring. I'm looking forward to the new and improved UI Options! :) Michelle _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
