UI Options and Transformation - possibly easier route

Clayton H Lewis clayton.lewis at Colorado.EDU
Tue May 3 20:07:36 UTC 2011

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 [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

Clayton Lewis
Professor of Computer Science
Scientist in Residence, Coleman Institute for Cognitive Disabilities
University of Colorado

More information about the fluid-work mailing list