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
[email protected] Inclusive Design Institute
OCAD University
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
