>> Err, could you please explain why? When inventing the whole
>> DataContext event machinery at least I had a large number of uses in
>> mind, including events that were to be consumed internally by cayenne.
>> Since you mentioned multi-threaded dispatch before: do you intend the
>> DataContext events to act as a bridge to user code only?
>>
>> Now, that I think a little bit more about the willPerformQuery use I
>> see that this is really more a delegate in the pure EOF sense: some
>> object that is called before a certain operation is executed and that
>> object has the chance of vetoing/influencing the flow of control. The
>> question that pops up now is: by which criteria do we distinguish
>> between which method calls go into the delegate interface and which
>> will be posted as events?
>> Maybe we can refactor the DataContext events a little bit more to
>> match your requirements?
>
> Since we started this discussion, I think we should take a step back
> and do a more systematic design of the access layer events and
> delegation tasks instead of current ad hoc approach.
Yes, the ad hoc approach was only taken by my misconception that we could
achieve the delegate functionality with events.
> 1. Delegation.
[...]
I fully agree here.
> Cayenne framework (we may not even force the implementation of certain
> interface to make it easier to create delegates that implement only one
> or two methods).
I like the interface approach. We could provide an adaptor class that
implements all of the methods in the interface just empty or with default return
values so that subclassers can inherit from that class and implement only the
methods they need. This would make the framework code easier, too: instead of
poking around with reflection we could just invoke the delegate method if one
is set: the compiler makes sure that the delegate has the right type.
The only counter-argument could be that classes with another concern (and
thus a different base class) would like to become delegate, forcing those
classes to implement the entire interface. I feel that this will be a rare case.
> 2. Events.
[...]
I fully agree here except for one point:
> In general listeners notification is decoupled from the
> thread that generated the event.
In general your statement is right except for cases where object graph
consistency matters. In those cases we might be forced to deliver notifications
synchronously. I'm using an EOF example simply because it's the first that
comes to mind:
When EOF saves changes to the database, all peer EditingContexts are
notified and try to merge the changes written to database back into their existing
EOs. To ensure object graph consistency this notification has to be delivered
synchronously because if it was delivered from a different thread the point
in time that object graph synchronization occurred was undefined.
So I guess we have to rework the existing notification mechanism to be able
to work in both modes: synchronous and asynchronous, right?
-dirk
-- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoServiceJetzt kostenlos anmelden unter http://www.gmx.net
+++ GMX - die erste Adresse für Mail, Message, More! +++
This archive was generated by hypermail 2.0.0 : Thu Oct 02 2003 - 04:29:18 EDT