I've written up the "broken trees" IoC issue that Michelle and Cindy ran into
this evening for FLUID-4171 -
http://issues.fluidproject.org/browse/FLUID-4192
At base, the issue could be traced to registering fluid.uiOptions.controls as a "rendererComponent" rather
than an "IoCRendererComponent", but this is hardly surprising, since so far there is still no documentation
for "IoCRendererComponent" (sorry). However, it does raise the issue that "one" of these renderer component
grades should simply become the default (and even the "antigenicRendererComponent" which is about to be
written) which also brings up the issue of naming again.
One option for now might be to just rename the current "IoCRendererComponent" to "rendererComponent" since
it seems to correspond to the sensible behaviour anyone would want, and then send the current
"rendererComponent" to "nonIoCRendererComponent".
As for naming, we could have the "antigenic" variety named "multiphaseRendererComponent"? Any other
suggestions for names? The important differences are that its lifecycle and semantics actually make a break
with "viewComponent" from which all renderer components are currently derived. This is particular obvious in
the handling of the "container" argument.
Right now a standard view component
- i) expects the "container" selector to be supplied on startup
ii) if it is not found, the creator function returns null, interpreting that the component is to be
"pruned away"
iii) constructs the DOM binder, resultingly, on startup
An "antigenic" view component - please suggest other names now
i) Takes no container on startup - and so probably has the signature of a "little
component"
ii) Therefore, exists at an "early lifecycle point" where it cannot be
operated by the user, but CAN
a) respond when asked for "produceTree" or "produceMarkup"
b) can also contribute information about I/O it requires to do to locate a
template
iii) Accepts the container (bindContainer()?) at some later point in the
lifecycle, at which point it
a) constructs its DOM binder, and is then prepared to
*) render itself (this is currently already a separate lifecycle point)
This "multiphase" behaviour is also not necessarily tied to the use of the renderer in the child component
itself. We could imagine a component which just produces its markup in a simple way, perhaps as a string (as
many of our "tiny view components" currently do) but can still cooperate with an overall pass of the
renderer, generating markup for a large page in a single step - in this case, this "non-renderer antigenic
component" would have its markup honoured in the wider renderer tree as a UIVerbatim. This would improve
performance in many cases - for example, large CollectionSpace pages tend to "twinkle" right now as lots of
these "tiny view components" are created late.
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
