On 26/01/2010 11:11, Colin Clark wrote:
Hi all,
Justin and chatted today about the big picture view for his very helpful
createRendererFunction() utility in Engage. This picks up from a conversation
that Michelle, Antranig, and I had during the framework sprint in Boulder back
in November.
In short, createRendererFunction() is intended so significantly simplify the
process of using the Renderer by automatically generating cutpoints from a list
of DOM Binder selectors. A pattern of use has been emerging in many of the
components that use it:
fluid.engage.myComponent = function (container, options) {
var that = fluid.initView(...);
that.render = fluid.engage.renderUtils.createRenderFunction(container,
that.options.selectors, {
selectorsToIgnore: ["foo", "bar"],
repeatedSelectors: ["bazes"]
});
};
It seems pretty clear that this is functionality we could offer free to users as part of
Infusion's own initView(). Here are some sketches of what it might look like, to
stimulate discussion. Antranig and Michelle, feel free to jump in if I'm missing any
details from our "Egg And I" conversation. I'll use the Navigation List as an
example.
1. Define a new special location in the options that house renderer-specific selectors.
The standard "selectors" object would be used for selectors that aren't needed
for rendering the initial view. We'll also need some kind of notation to identify
repeating selectors.
selectors: {
gridToggle: ".flc-navigationList-gridToggle",
linkContainer: ".flc-navigationList-linkContainer"
},
rendererSelectors: {
listItems: { // This is a fairly awkward notation for repeating selectors;
suggestions for alternatives?
selector: , ".flc-navigationList-listItem"
repeat: true
},
image: ".flc-navigationList-image",
title: ".flc-navigationList-title",
description: ".flc-navigationList-desc"
}
Yes, it is pretty awkward. One option might be to allow substructure
within the "selectors" block - this would also retain the existing
top-level options structure - perhaps something like:
selectors: {
gridToggle: ".flc-navigationList-gridToggle",
linkContainer: ".flc-navigationList-linkContainer",
renderer: {
image: ".flc-navigationList-image",
title: ".flc-navigationList-title",
description: ".flc-navigationList-desc"
},
repeatedRenderer: {
listItems: ".flc-navigationList-listItem"
}
}
I should note that with respect to yesterday's work on
makeProtoExpander, colons are no longer required when used as the key/ID
of a repeating set in the component tree. They are, however, still
required when parsing the markup template, which is a rather harder
problem to solve.
2. We'd need to modify fluid.initView() to merge the "selectors" and
"rendererSelectors" into a unified DOM Binder. There's one catch here--some selectors may
not correctly match after rendering. For example, the description element in Navigation List won't
be rendered if it's not present in the model. We'd need to implement some kind of
selector-rewriting algorithm to make this work ideally.
Yes, that's right, but to clarify, I don't think we would visibly
rewrite the selector - we would just fix up the DOM binder so that it
knew how to continue to find the "same nodes" after the markup is
rewritten. People should not expect to just randomly reach into a
"selectors" block and operate the selectors by themselves.
3. If rendererSelectors is present, attach a render() function to the
components (perhaps along with some way to customize the Renderer options as
well).
Thoughts?
Colin
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
