Cindy, I think you can keep moving forward with your current plan for UI Options and UI Enhancer development for the Infusion 1.4 release. Clayton, if you want a hand with specific improvements to either component based on Antranig's brainstorming, I'm happy to lend a hand.
Colin On 2011-05-02, at 9:15 AM, Li, Cindy wrote: > Yes, reorganizing UIEnhancer in the IoC way is very well in my plan for this > week. I will get there once I get the tests for text slider and UIOption back > to work, hopefully later today or tomorrow. The tests still need to be > re-visited later on for properly testing the re-constructed sub-components > and also the integration tests. > > Is the idea of "progressiveChecker" already in the framework? Can I go ahead > with the idea of "UIOptionsDecoder" when I get there? Let me know if > framework changes are required in front or a modified (or new) version of > implementing this "model transformation" surfaces. :) > > Cindy > ________________________________________ > From: Antranig Basman [[email protected]] > Sent: 30 April 2011 16:52 > To: Clayton H Lewis; Li, Cindy; Fluid Work > Subject: UI Options and Transformation - possibly easier route > > Thinking about this overnight, I thought we might be able to take a slightly > easier route at least for this > particular case, and also one more similar to the one we currently take with > the Uploader. Unfortunately, a > common point between all strategies is reorganising the UIEnhancer so that it > is IoC-driven, which is the > "other end" of the task to the one I talked most about with Clayton > yesterday, which was the "model > transformation" end. > > The idea is to use what is currently called the "progressiveChecker" (which I > think in the light of this new > use case we should give a more generalised name, such as > "conditionalTypeFount" :P) to produce an IoC "type > tag" that will guide the instantiation of the TableOfContents subcomponent of > the UIEnhancer. > > A good step i) would be to put an extra container component in between > UIOptions preview and UIEnhancer, > perhaps called "UIOptionsDecoder". We would then ii) say something like > > fluid.defaults("fluid.uiOptions.decoder", { > components: { > checker: { > type: "fluid.progressiveChecker", > options: { > checks: [{ > feature: "{uiOptions}.model.toc", > contextName: "fluid.uiOptions.tags.tableOfContents" > } > ] > }, > enhancer: { > type: "fluid.uiEnhancer", > options: ..... other options here .... > } > } > > Then demands blocks would be issued against the enhancer, as follows: > > fluid.demands("fluid.tableOfContents", "fluid.uiEnhancer", { > funcName: "fluid.emptySubcomponent", > options: [] > }); > This one "resolves away" the ToC component (which we would have to put in > defaults under this solution) if > the tag is not found > > fluid.demands("fluid.tableOfContents", ["fluid.uiEnhancer", > "fluid.uiOptions.tags.tableOfContents"], { > options: [ .... whatever options required here ....] > }); > If the tag is there, this demands block matches better than the previous one > and would enable the ToC > subcomponent. > > This would cut down on the complexity of modelTransformation a lot, although > it is something we would > probably have to have an answer for in time - this system could deal with > sequences of boolean conditionals > (using the "optimality theory model" :P) as it stands, and perhaps could be > extended with a calculus of > better "type founts" to deal with some other cases. In time we would probably > unify the calculus in "type > founts" with whatever we have in model transformation so they could use the > same primitives - and extend the > progressiveChecker etc. so it could spit out components with genuine amounts > of configuration rather than > just a single type tag as it does now. > > > > > > On 30/04/2011 00:43, Antranig Basman wrote: >> Clayton is presenting on the Fluid IoC system and its capacity to enable >> dynamic adaptation to users' >> preferences next week in Vancouver at CHI - http://chi2011.org/ - so we had >> a session this evening looking >> at the UI Options code which is the place in our codebase where these ideas >> are closest to being embodied. >> >> We were looking to provide a use of Colin's early-stage >> "ModelTransformation" system which was put into >> sneak peek for 1.3 for the use case of transforming back-version Uploader >> options, applied to the case of >> automatically generating configuration suitable for driving the UIEnhancer, >> given the UI-driven model which >> is bound to the user's selection controls in UIOptions. Right now this >> pathway is hard-wired - we don't need >> to demonstrate anything particularly ambitious for the talk, but it looked >> like a relevant use-case for >> showing the whole process end to end was for transforming between the >> boolean field "toc" controlling the >> visibility of the Table of Contents generated for the page, and some IoC >> configuration for actually driving >> this in UIEnhancer. >> >> The plan was to substitute this at around line 537 of current UIOptions.js, >> where configuration for the >> UIEnhancer is generated - this would be written as an IoC "deferredCall" >> expander driving an instance of >> fluid.model.transformWithRules transformer from ModelTransformation, taking >> {uiOptions}.model as input and >> generating "some suitable configuration" - preferably in the form of a full >> subcomponent definition for the >> fluid.tableOfContents widget attached to the enhancer. Clayton would have to >> write a new "condition >> expander" rule (analogous with the renderer's condition expander) to plug >> into the transformer to make this >> transformation work. The ModelTransformation code is very provisional still, >> as is this slightly clunky >> workflow for IoC, but it would demonstrate the basic principles in action. >> >> When we got to the UIEnhancer code, we discovered that the TableOfContents >> subcomponent of the enhancer is >> actually not right now IoC-driven at all but still uses the original >> implementation of a steam-driven manual >> subcomponent whose instantiation is controlled by JS logic. So, I guessed >> that this might well be the very >> work which Cindy was thinking of doing this week in any case, so I wanted to >> get you two in touch so that >> the work of one could benefit the work of the other, and vice versa :) >> >> I think it would be great if the hard dependence between UIEnhancer and >> TableOfContents could be cut, and at >> the same time demonstrate the the principles of configuration-driven >> transformation in operation. This >> workflow is also crucial to the GPII work that we are taking on and will be >> demonstrating at Washington in >> July. >> >> I myself am also away presenting on IoC (!) this week in Portland at JSConf >> - http://2011.jsconf.us/ - but >> will be in touch by mail and probably sometimes in messaging to help out, >> but I thought I would set out the >> plan and get you guys in touch to get the ball rolling. If it is too >> ambitious to get UIEnhancer refactored >> by the end of the week, Clayton will probably try to put together a >> standalone demonstration of "some >> component" containing the TOC widget whose configuration is derived by >> transformation. > _______________________________________________________ > fluid-work mailing list - [email protected] > To unsubscribe, change settings or access archives, > see http://fluidproject.org/mailman/listinfo/fluid-work --- Colin Clark Technical Lead, Fluid Project http://fluidproject.org _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
