Johan Compagner wrote:
The extra memory for the ClickListener is negligible and does give you
more flexibility because now you can have more than one interested party
for the link click. My use case (fetch nested component, add listener)
was already answered sufficiently by Martijn (bad OO, components should
publish own events that make sense in the problem domain), but I still
an eventlistener-based design could have merit (see the move towards
Delegation Event Model in AWT:
http://java.sun.com/j2se/1.3/docs/guide/awt/designspec/events.html).
While wicket is not swing or awt, it's an interesting read.
with the link abstract class you don't have any extra memory overhead
but with the listener interface you have quite a lot because you need
and extra reference in link itself, that holds an extra List (that again has
its own stuff)
The trick in awt is to only hold one reference to a listener that
recursively fires the event on registered listeners (see
AWTEventMultiCaster)
and then you have an extra instance of the listener itself which by itself
has its internal representation
Don't underestimate this. especially because we also can use them in
tableviews with a lot of cells.
But as i said, if you want a listener interface then you can build it quite
easily
True, but of course my goal is not to create a fork, but to discuss
different views on the used event model.
I'm not an expert on memory or profiling, so I'll believe you. I do
think that such a choice should not only be made on the basis of memory
usage. But since the choice is already made, I'll go with it until I can
find a more convincing argument (although the link I supplied has some
quite convincing ones).
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]
