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