Model Transformation and the UI Options component

[Antranig Basman]

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.

Cheers,
Antranig.