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.
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
