Options merging and destructible things - FLUID-3675

[Colin Clark]

Antranig,

Thanks for the summary and the quick implementation of the preserve policy for options merging. Since this functionality is in trunk now, we can use it as soon as necessary in CollectionSpace to simplify the effort of passing around models and appliers. On Monday, I'll start in on writing the facility to instantiate components of various categories/grades, so that ordinary users need not define their own merge policies under ordinary circumstances--things will "just work." This will dovetail nicely with our plan to make Justin's renderer function feature a core part of Renderer-bearing components soon.

Colin

On 2010-06-18, at 1:04 AM, Antranig Basman wrote:

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

---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org