cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: ROP listener semantics
Date Tue, 26 Feb 2008 18:20:23 GMT
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).

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.

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.

> 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  


On Feb 26, 2008, at 7:38 PM, Kevin Menard wrote:
> Forgive the simplistic nature of this question, but I want to verify  
> my
> understanding of listeners.
> If a server entity has a pre-persist listener and the corresponding
> client entity does as well, then both listeners will be executed, with
> the server called first?  Moreover, any modifications made at the  
> server
> level will be reflected back in the client?
> The simple case at hand is to update a date creation field.  I have to
> have this listener in the server because objects can be created over
> there.  I thought I needed to duplicate this logic for the client as
> well, but after stepping through the debugger, I don't think I have  
> to.
> Thanks,
> Kevin
> -- 
> Kevin Menard
> Servprise International, Inc.
> Remote reboot & power control for your network
>                  +1 508.892.3823 x308

View raw message