Timo Rantalaiho wrote:
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.
I knew about WICKET-1312, but hadn't thought of broadcasting domain
object typed events, just things like onClick and such which gives too
little information. Thanks for the eyeopener!
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.
Maybe listeners could be registered using weak references so that the
objects are still garbage collected even when the listener is still alive.
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
Matthijs
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
