thank you! I think I'm making progress towards a demo and will let you know if I get stuck on somehting On May 3, 2011, at 12:58 PM, Colin Clark wrote:
> 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 > Clayton Lewis Professor of Computer Science Scientist in Residence, Coleman Institute for Cognitive Disabilities University of Colorado http://www.cs.colorado.edu/~clayton _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
