On Mon, 07 Jul 2008, Matthijs Wensveen wrote: > The thing is that when using Ajax you have to specifically add > PersonViewer to the AjaxRequestTarget when 'some other component' > modifies the Person object. The problem is that 'some other component' > might not even know about or have access to PersonViewer (maybe it's a > 3rd-party component). OnModelChanged does not work in this case, because > there is no call to setModelObject, just to some setter of the Person > object.
Yep, in our current project we use the WICKET-1312 "broadcaster" approach to solve this. This means that the logic of which component needs to be repainted when something happens is in the UI components. (The domain logic itself we try to put in the domain objects.) So in our model, the other component modifying the Person object would broadcast a PersonModifiedEvent to all PersonModificationReceiver components, who could then act accordingly (typically add themselves to the Ajax request target). There's not a lot of automagical intelligence there, but we have found this way clear and effective. All relationships are "static" on component class level and navigable in the IDE. The proliferation of events and receivers must be watched out for though. > While Ajax does very nice things to the GUI, it kinda messes up the > model-driven (as in wicket model) approach to gui development. That is > why I was thinking about some aspect-oriented solution to let components > know about model updates, even when they keep a reference to the same > object. That's true. It's a pity that for now, Java AOP solutions are still a bit invasive (AFAIK, if you know of some really neat and transparent implementation without -javaagents or special compilers or some such nuisance, I'd be glad to hear :)). We tried sharing models and making them more intelligent and models sending events to registered listeners and whatnot dead chickens before arriving at the current broadcast/receiver approach. When the components are "physically" far away from each other, sharing the model or handling registration and deregistration can get hairy. And to avoid memory leaks, removing the listeners when components are being replaced (e.g. repeater children recreated) should be taken care of carefully in a traditional event-listener mechanism. However, more experimentation is definitely needed on this, and I'd be very interested on hearing any experiences and ideas! It seems that ajax will be around for some more years, whether we like it or not, so best to make the best out of it :) Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations Oy <URL: http://www.ri.fi/ > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
