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
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
