Documenting how to customize UIO and UIE

Cheetham, Anastasia acheetham at ocad.ca
Wed Aug 31 16:27:06 UTC 2011


On 2011-08-31, at 12:03 PM, Michelle D'Souza wrote:

> Given that we are expecting to overhaul the API for UIO in 1.5, I feel that we should be selective in what we document in 1.4. It seems to me that the top level UIO API is about as deep as we want to go. 
> 
> I think it would help if I had a little more information about the current situation. Do you know what implementers are configuring now? Any thoughts on what they will likely want to configure right away? Which of the examples you gave cannot be configured in the top level API?

Most of the scenarios I listed involve options on a subcomponent. With the options-munging, that's almost "top-level." Then general form is:

fluid.uiOptions.fatPanel(".myContainer", {
    <subcomponentName>: {
        options: {
            <subcomponent options>
        }
    }
});

So, for example so provide a path to a custom Preview temlate:

fluid.uiOptions.fullPreview(".myContainer", {
    preview: {
        options: {
            templateUrl: "../templates/CustomPreview.html"
        }
    }
});

The UI Enhancer and Page Enhancer do *not* have options munging implemented, so any customization of their subcomponents requires the old form of very nested options, or demands blocks (which require an understanding of the specificity of any existing demands blocks). Things you might want to customize for UIE include selectors related to the table of contents, as well as event listeners.

Also, the UIE is the parent component of the settings store, so any configuration of that (e.g. expiry date of the cookie) would have to go through UIE.

-- 
Anastasia Cheetham     Inclusive Design Research Centre
acheetham at ocad.ca            Inclusive Design Institute
                                        OCAD University



More information about the fluid-work mailing list