Sketching out the successor to fluid.engage.renderUtils.createRendererFunction()

Antranig Basman antranig.basman at
Tue Jan 26 19:22:41 UTC 2010

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

More information about the fluid-work mailing list