Dirk,
I am forwarding this to the list, since it looks like your address
@xanthippe.ping.de got unsubscribed automatically after a few bounces, so
the list management software thinks that you are no longer subscribed and
rejects the messages from this address.
You other address is still subscribed and should work fine.
Andrus
----------Forwarded message ----------
Date: Mon, 18 Nov 2002 21:24:21 +0100
From: Dirk Olmes <dir..anthippe.ping.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1)
Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Andrus Adamchik <andru..bjectstyle.org>
Cc: cayenne-deve..bjectstyle.org
Subject: Re: Callback methods [Was: createPermId in DataContext]
Andrus Adamchik wrote:
>>> 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).
Ok, after thinking a little bit more about it, I'd really go for (2). This
seems to be the loosest coupling between the DataContext and its notified
object.
> I would still prefer an outside listener (or delegate :-)) instead of
> checking each DataObject.
Ok, no objection.
> It just seems cleaner than doing "instanceof".
> Objects are not committed one by one, instead they are committed in a
> single transaction.
I meant the mechanism to work along the lines of validateForSave() from EOF.
Upon certain control points in the framework all the objects taking part in
the current transaction are notified and can take appropriate action before
they're written out to the database.
> 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.)
I don't think the two approaches are contrary. What I don't like about the
single DataContext notification/delegate method is that in the long run
there'll be multiple implementations of validation / pre/post commit
notifications of the DataObjects etc. flying around. I'd rather have a
single framework provided solution rather than writing my own.
Of course I could always go ahead and create my own implementation but then
I'd have to maintain my own cayenne-contrib project. Then again I see that
there's a thin line between framework and userspace features.
To dig a little bit further into this problem area I'll go ahead and try to
implement a demo solution as basis for further discussions, o.k.?
-dirk
This archive was generated by hypermail 2.0.0 : Mon Nov 18 2002 - 15:31:56 EST