cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Menard" <kmen...@servprise.com>
Subject RE: ROP listener semantics
Date Tue, 26 Feb 2008 18:42:51 GMT
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Tuesday, February 26, 2008 1:20 PM
> To: user@cayenne.apache.org
> Subject: Re: ROP listener semantics
> 
> Per my other reply to a similar question, there are no callbacks or
> listeners on the client at all (and for that matter they do not work
> with nested contexts either - only the topmost parent context's object
> events will cause mapped callbacks to fire).

This is a bit surprising to me, because I think that they do work.  For
my server class hierarchy I have one base class that I've made implement
LifecycleListener.  I've done the same for the client classes.  In the
modeler, I mapped each of these classes as listeners at the DataMap
level.  I couldn't get it to just acknowledge that these were listeners
based on the interface, so I mapped the pre-persist methods for each.

I then fired up the server in a debugger and a client in the debugger.
Accessing a simple CRUD page in the client, both pre-persist methods
were entered: the base server class one and the base client class one.

> While this is consistent, it is far from user-friendly. The problem is
> not technical (it is easy to invoke callbacks anywhere), but rather a
> design one. My assertion is that callbacks and listeners will likely
> be very different between the layers. In your example for instance, it
> wouldn't make sense to set the 'creation_date' via a callback twice.
> This in turn presents a challenge in mapping callbacks in the modeler.
> This task is hard as is (I just tried to remap my manual callbacks
> using M3 Modeler... not easy at all ... we may need alternative UI for
> that task). If we'd have to map two separate sets of callbacks, client
> and server, things will get even messier.

Perhaps what I'm seeing is environment related then.

I think if the semantics of execution order are well-defined, it's not
as big a problem.  If I can be assured that the server will execute and
the changes will end up reflected in the client, then that's good enough
for me.  I can then use the client listeners for executing stuff that
really only belongs to the client.

I do agree that mapping two different sets of callbacks is going to be
messy.  I'd probably keep the same UI but have a checkbox or something
for client versus server.  Where it will likely start getting tricky is
when we can finally use a single class hierarchy for server & client.

> As a quick fix I was thinking of enabling manual callbacks and
> listeners on the ROP client, but still avoid exposing server callbacks
> on the client.

Agreed.  But, I'd like to avoid anything that makes unification of
server & client hierarchy a harder task than it already is.

> > Moreover, any modifications made at the server
> > level will be reflected back in the client?
> 
> This is actually a separate issue from callbacks/listeners. And we
> need to fix it .. badly... The object diff exchange protocol supports
> sending server-side changes back to the client (and in fact we are
> using that - for generated primary keys), but we also need to capture
> and send back the changes that happened to objects as a result of
> callbacks. IMO this is a major task that we'd rather do sooner than
> later.

Gotcha.  In this example, it looked as if the changes were sent back.  I
haven't looked into enough to see if I just did a refresh query
somewhere along the way though.

We can take the rest of the discussion to the dev list I guess.

-- 
Kevin

Mime
View raw message