FLUID-4925: Implement "wave of explosions", eagerly instantiating all component shells before their contents

Description

Building on the FLUID-4330 ginger world work, and preparatory to the "wave of promises" asynchronous ginger world, we can offer a significant improvement in regularity to the users of IoC by eagerly instantiating "component shells" and any type founts preferentially to evaluating any other contents of their options in the ginger process. This will allow reliable type-based access to components without requiring a dependence on instantiation order or reliance on hard-coded paths. For example, in this situation in the Uploader, the base component

fluid.uploader.multiFileUploader
 |
 +--- fluid.uploader.fileQueue
 |
 +--- fluid.uploader.html5Strategy
       |
       +--- queue

We would like to write the injection of the fileQueue as

queue: "fluid.uploader.fileQueue"

but instead must write it as:

queue: "{uploader}.queue"

This is because despite being a more deeply nested subcomponent of the base, we can't guarantee that the framework has not chosen an instantiation order which recurses more deeply on html5Strategy and has not yet seen the typename of the queue as "fluid.uploader.fileQueue" as the member at path "queue". The former form is preferable since it imposes less tight binding on the exact location of the fileQueue.

In the "wave of explosions" a wave of instantiations will spread eagerly from the root, in breadth-first order, with the usual priority given to type founts, and ensure that in virtually all cases by the time the body of any component options are expanding, the "type skeleton" of the entire component tree will be available (barring any components whose types depend on some portion of their options body material)

Comments

• Antranig Basman commented 2015-01-30T10:04:20.869-0500

  A further requirement - we should try to eliminate the cumbersome piece of memory-ware "fluid.typeFount" and have the framework eagerly evaluate the shells of any components which appear to have the FORM of dynamic grades first amongst a set of siblings - since these are more likely to encode type decisions that might be consumed by other components.