fluid.initRendererComponent options: any 'unsupported'?
antranig.basman at colorado.edu
Wed Dec 8 21:31:11 UTC 2010
I think everything under "rendererFnOptions" should be considered
unsupported. In general I think we want to reorganise this options set
to that the layout makes more sense to users and they don't have to
necessarily hunt around in substructures.
Yes, "model" is not necessary on rendererOptions since everything is
governed by the top level model, and similarly for elements of
"expanderOptions", this doesn't need to be configured more than once.
I guess I have *some* concerns about the stability of all of this API
since it has not really been through much review and consideration. For
example the "selectors", "repeatingSelectors" and "selectorsToIgnore"
pattern worries me a bit as well - I presume we are designating this
entire function as part of "sneak peek" in any case, since it is all new
in this release.
On 08/12/2010 14:09, Cheetham, Anastasia wrote:
> Hey, Antranig,
> I'm just going over the fluid.initRendererComponent() and its options, and I wanted to double-check whether or not any of the options would fall into the "unsupported" class.
> Below, I've listed the options I've found so far. Would any of these be considered "unsupported" i.e. we don't really want users to know about them?
> There seem to be "repeated" options - top level options that re-appear inside options blocks that get passed down (e.g. model) - are these things that the user should be instructed to provide at the top level, but NOT at the lower levels (i.e. the framework will take care of propagating it down)?
> model<would this be the same as above?>
> model<same as above?>
> resolverGetConfig<same as above?>
> resolverSetConfig<same as above?>
> <would these be the same as above?>
More information about the fluid-work