UI Options and Transformation - possibly easier route

[Li, Cindy]

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.