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