> -----Original Message----- > From: Andrus Adamchik [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 26, 2008 1:20 PM > To: [email protected] > 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
