Hi Dirk,
> Date: Mon, 18 Nov 2002 12:17:53 +0100 (MET)
> Subject: Re: Callback methods [Was: createPermId in DataContext]
> From: "Dirk Olmes" <dir..anthippe.ping.de>
> To: <andru..bjectstyle.org>
> Cc: <cayenne-deve..bjectstyle.org>
>
>> I like the delegate or listener approach better. I don't want DataObject
>> interface to grow bigger, rather I'd like to make it smaller in the
>> future.
>
> I'm a bit confused by your statement. What exactly do/don't you like?
Sorry if I did not make myself clear. Out of 3 options [(1) hooks in
DataObject, (2)independent listener, (3) independent delegate] I would be
looking into (2) and (3). Thanks to Craig for reminding about the
distinction between (2) and (3).
> I don't want to extend the interface of DataObject. Rather, I'd create
> Interfaces that specify the API that will be called. To stick with the
> previous example, I'd create an Interface ITransactionCallbacks:
>
> public interface ITransactionCallbacks
> {
> public void willCommit();
> public void didCommit();
> }
>
> Now each Data Object is free to implement this interface on a per class
> basis. This approach would even work with non-CayenneDataObject rooted
> objects.
>
> In DataContext I'd check for each candidate of the current commit whether
> it is instanceof ITransactionCallbacks or not.
I would still prefer an outside listener (or delegate :-)) instead of
checking each DataObject. It just seems cleaner than doing "instanceof".
Objects are not committed one by one, instead they are committed in a single
transaction. So it makes sense to generate a single event with DataContext
as a source. Listener can easily query DataContext for the list of objects
to be committed and do the necessary operations on them (including
validation, audit, etc.)
Any reason you think this might be a problem?
Andrus
This archive was generated by hypermail 2.0.0 : Mon Nov 18 2002 - 10:38:32 EST