fluid.initRendererComponent options: any 'unsupported'?

[Antranig Basman]

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
> resources
> resolverGetConfig
> resolverSetConfig
> rendererOptions
>      model<would this be the same as above?>
>      applier
>      autoBind
>      document
>      debugMode
>      idMap
>      messageLocator
>      messageSource
>      renderRaw
>      cutpoints
> rendererFnOptions
>      cutpointGenerator
>      expanderOptions
>          ELStyle
>          IDescape
>          model<same as above?>
>          resolverGetConfig<same as above?>
>          resolverSetConfig<same as above?>
>      noexpand
>      rendererOptions
>          <would these be the same as above?>
>      templateSource
>      rendererTargetSelector
> selectors
> repeatingSelectors
> selectorsToIgnore
> strings
> messageResolverFunction
> parentBundle
> protoTree
> produceTree
>
>
>
>