> -----Original Message-----
> From: Andrus Adamchik [mailto:andru..bjectstyle.org]
> Sent: Tuesday, February 26, 2008 1:20 PM
> To: use..ayenne.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
This archive was generated by hypermail 2.0.0 : Tue Feb 26 2008 - 13:43:26 EST