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 - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
