Options merging and destructible things - FLUID-3675

[Antranig Basman]

Colin and I had a good talk this afternoon which suggested a few ways 
out of our current problems with "non-model-contract" items (such as, 
for example, ironically, models) being destroyed through being passed 
through the options merging process.
Whilst (as it seems with everything) a long-term good solution to this 
issue lies with the use of IoC, in the short to medium term it seems we 
can get by with the use of a slight tweak to our options merging 
algorithm, in the form of a new directive called "preserve" - this 
designates a path which holds a "destructible item" such a model, 
applier, or other "live piece of that" which rather than being "merged" 
will simply be copied directly into the component's options.

http://issues.fluidproject.org/browse/FLUID-3675 is the JIRA created for 
this. Initially signed over to Colin but I found myself with what 
amounted to most of a test case for part of the functionality and my 
head filled with part of the soln, the first part of the solution is now 
in trunk. You can consult the new test case in FluidJSTests.js to see 
the idea - but it works similarly to the existing directive we had 
called "replace".

In order to make this convenient for everyday users of the framework, 
this kind of directive (expressed in the component's default options) 
needs to be factored away into what in a more unenlightened era might 
have been called a "base class". Today, we imagine the use of component 
"categories" or "grades" - which express the identity of the 
initialisation function used to first construct the "that" in the 
creator function. In these terms, we currently just have two "component 
grades" - which are "Little Component" and "View Component". In the near 
future we expect to have a healthy lattice of these things - which again 
in "old-world monkeys" could be termed "mixins" - for example, a 
component may be model-bearing, view-bearing, renderer-bearing or any 
valid combination of these (clearly view-bearing implies model-bearing, 
and renderer-bearing implies both - actually this is starting to look 
more like a straight hierarchy ...)

             fluid.defaults("fluid.tests.testMergeComponent",
                 { mergePolicy: { model: "preserve",
                                  applier: "preserve"}});


It is important in all other cases, that options merging continues to 
apply the old semantics of constructing new containers whenever 
possible, to avoid aliasing together the various elements of the object 
trees that participate in merging. This is important to avoid the really 
bad consequences of facilitating people to inadvertently reach into the 
actual component defaults record itself, for example, and corrupt it for 
all time. We experimented briefly with a "conservative merge" that 
copied "source" containers whenever possible, but this already showed 
failures within some of the tests for the LayoutReorderer - which were 
revealed to be "alias-prone" in that the tests now failed to be 
isolated, and execution of some tests could cause subsequent tests to fail.