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
later.
Thanks,
Andrus
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
www.servprise.com +1 508.892.3823 x308
