Andrus wrote:
> Here is an idea - move all functionality of
> DataContextTransactionEventHandler to ContextCommitObserver (and get rid of
> DataContextTransactionEventHandler alltogether).
Uhm..how embarrassing! That is exactly what I was looking for, thanks. It
really makes sense since DC and ContextCommitObserver are already tightly
coupled anyway.
> A new ContextCommitObserver is always instantiated for each commit, and
> therefore can safely store the state.
yes, perfect. I'll just have to make sure it isn't GC'ed before the end of
commitChanges(); as of right now it's just hanging around pretty loosely.
> It (and its superclass) has callback methods invoked on commit, rollback,
> exceptions and such. If we need extra API in, we can add it...
I guess when I was looking over it I didn't pay close attention because I
was looking for some kind of event handling. The current -Observers are
more like delegates, right? Should we make this our terminology, -Observer
for directly invoked methods and -Listener for things sent around via
Events? Otherwise things will get very confusing in the future or for new
users. Or just rename all *Observers to *Delegate once and for all? yes I
know, backwards compatibility..
> >3) a new dataContextRolledBack event so that the handler can clean up
> >properly
>
> +1, as a part of ContextCommitObserver.
OK. I'll try to do this tomorrow and see where it goes.
Holger
This archive was generated by hypermail 2.0.0 : Mon Jan 20 2003 - 15:28:00 EST