CSpace help: Passing a ChangeApplier to a decorator

Antranig Basman Antranig.Basman at colorado.edu
Tue Nov 10 16:54:07 UTC 2009

Anastasia Cheetham wrote:
> On 10-Nov-09, at 1:18 AM, Antranig Basman wrote:
>> ...supplying an "applier" as an option
>> is only somewhat sound...This instance of the model starts
>> out identical to the closed-over model, but can quite easily diverge -
>> and actually will be corrupted if the applier passes through the process
>> of options merging ...
> Antranig, thanks so much for your explanation of things. I think I'll 
> have to take a close look at the ChangeApplier code and the options 
> merging code to *truly* understand what's happening, but I do 
> *basically* understand it.

Well, it should be enough to deal with the basic principles which are in
operation, although I guess reading the code couldn't hurt :P

> We're giving your suggestion a try, but I can't help but thinking in the 
> back of my head "there's got to be a better way." I suspect that there 
> must be a different way for us to relate our number pattern chooser to 
> our model, a "more proper" way - one that allows us to use the Fluid 
> Framework functionality in a straightforward manner to accomplish what 
> we want to accomplish. I'll ponder it a bit more...

Well, my first wonder is why you do not tie the updating of the model to 
the ChangeApplier event infrastructure directly, rather than trying to 
fire your own change event directly. I assume that there is already a 
change event being directed at some model somewhere as a result of the 
UI event.

"Avoid starting each sentence with 'Well,'"


More information about the fluid-work mailing list