Broken trees, names

[Antranig Basman]

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.