UI Options and Transformation - possibly easier route

Tue May 3 18:58:54 UTC 2011

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 [antranig.basman at colorado.edu]
> 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 - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work

---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org