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