Hi,
possibilities / solutions to unsolved problems. What I not yet
understood, why is this a better approach compared to extending one of
existing components and implementing the extensions by means of the
existing hooks?
a) for implementing behaviour that is not specific to one component
in the same way the AttributeModifier is not specific to one component
b) for combining different behaviours with the same component,
extending classes is fixed and not very suitable for mixing stuff.
c) clever behaviours could do a lot of very helpful magic in a very
transparent way. like resolving things like: two things want to use
the onchange="" event of a tag; a thing the AttributeModifier is not
very helpful at all.
If you want an example, look at the ajax dropdownchoice (the wicktor
thread in wicket-user), thats the use case my idea comes from. What I
wanted to do is a behaviour which refreshes dropdownlists using
javascript (ajax alike) without requiring a new request. I needed to
derive a new dropdownchoice for this although I almost nowhere
enhanced the dropdownchoice itself. I want to attach a "refresh other
lists <x> using client side javascript" (where <x> is another wicket
component) to the existing dropdownchoice component. I cannot give
hard facts for this but my instinct says I should not touch the
dropdownchoice for this at all.
Regards,
Ralf
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
