I realised after everyone turned in on Wednesday that this would be a
really good thing to have in advance of the merge :) Colin, I wonder if
you could do the honours and look over particularly
http://source.fluidproject.org/svn/fluid/infusion/branches/FLUID-2881/src/webapp/framework/core/js/DataBinding.js
and
http://source.fluidproject.org/svn/fluid/infusion/branches/FLUID-2881/src/webapp/framework/core/js/Fluid.js
(the corresponding test cases in the usual places) in search of the
peculiar, ineffective or downright offensive :P I remembered now what I
thought would be the most problematic aspect of the merge (and even the
work in general) which was the violence done to the implementation of
the Fluid events system in order to enable this function to be reused in
the new transactional ChangeApplier. The motivation may be a little
unclear, so here it it - the new ChangeApplier in several situations
needs to "assess in advance" the set of listeners which will fire, and
if necessary, amalgamate the listeners which will be upcoming to be
triggered by different paths. This was something that the analogous
system in RSF was never very good about but should here be "solved" -
for example, if there is a listener attached to "*" and during a single
transaction there are changes made to path1, and then to path2, the
listener should fire only ONCE at the end of the transaction ( but be
supplied an amalgamated change list). In order to support this, the
fluid events impl has become a little gnarled - it seemed worthwhile to
try to reuse this since there was the functionality of "namespacing" of
listeners implemented there which seemed a useful and orthogonal
facility to support in the new ChangeApplier (it was actually also
supported in ChangeApplier v1 but I don't believe anyone ever used this).
As a reminder to all, we are considering this functionality for "speedy
merge" into infusion trunk since it seems that it will be highly useful
for CollectionSpace and allow the removal of a good collection of code
across the app as well as in the DataContext. Comments and reviews
welcomed from all,
Cheers,
Antranig.
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
