Core framework upgrades - FLUID-3658 and FLUID-3680

[Antranig Basman]

Having finally completed a working implementation of the "protocomponent 
expander" a lot of work is now unblocked for merging into trunk. This is 
being somewhat "fast tracked" since it will aid the CollectionSpace work 
in a few areas.


FLUID-3658 - protocomponent expander

CSpace has been tied to an unofficial expander which was implemented as 
part of Fluid Engage for a number of months now, and also has various 
private implementations of functionality which is now provided by 
"expanders". There are three expanders currently implemented:

fluid.renderer.selection.inputs - does the work of expanding a UISelect 
component into a set of matching UIInputs (for use as radio buttons or 
checkboxes) - this is functionality which was programmatically provided 
by fluid.explodeSelectionToInputs

fluid.renderer.repeat - takes a section of component tree and replicates 
it once for each element of an array found in the backing model (taking 
care of appropriate bindings)

fluid.renderer.noexpand - this is applied not to primary component tree, 
but is used to "bracket off" pieces of component tree which have 
unexpectedly appeared in what the expander considers to be "raw model" - 
for example, inside the arguments to a decorator. The need for this was 
suggested by Yura on observing that in CSpace, there are some 
renderer-bearing components attached as decorators whose arguments are 
again component tree - which must NOT be expanded by the expander the 
first time round.

Documentation will be forthcoming, but in the meantime please consult 
the test cases at
http://source.fluidproject.org/svn/fluid/infusion/trunk/src/webapp/tests/framework-tests/renderer/js/RendererUtilitiesTests.js


FLUID-3680 - transactional ChangeApplier

This will be useful in CollectionSpace to replace some of the code used 
with "Data Context" - but is a longer shot than the expander which will 
be useful right away. The test cases mainly demonstrate transactionality 
through the work of "guards" which respond to changes can choose to veto 
them, therefore backing out of the transaction - whilst all the same 
being able to observe a "private" model state where the change has been 
applied before it is backed out - see the last test in file
http://source.fluidproject.org/svn/fluid/infusion/trunk/src/webapp/tests/framework-tests/core/js/DataBindingTests.js

Another new feature of this ChangeApplier is "change culling" - changes 
which (perhaps after adjustment through a guard) no longer change the 
state of the model are "culled" and do not cause notifications to listeners.

Tests are required for demonstrating transactions externally - the 
protocol for this is to call applier.initiate() which then returns a 
FURTHER applier which lives in the transactional world. This applier in 
addition to the standard applier methods has methods "commit" which will 
commit the changes in it, unless they have been requested to be 
cancelled by a failed guard. Unless the "commit" method is called, any 
changes made in the transactional applier will be ignored, and if/when 
it is called, they will all be applied at once (generating a SINGLE 
notification to any listener(s)).


The next most immediate work is on creating "renderer components" since 
there are a number of awkward points in the CollectionSpace workflow 
relating to collecting and fetching markup templates in complex 
rendering scenarios.