Code review for Transactional ChangeApplier - branch 2881

[Antranig Basman]

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.