I liked your idea and gone ahead with implementing it. It doesn't break anything, and it abstracts both ajax handlers and attribute modifiers better. I made a couple of changes to your original suggestion though:
* I made it an interface (IBehaviour) instead of an abstract class. In this case, there was no reason (no behaviour) for an abstract class so an interface is more flexible for users. * AbstractBehaviour serves as an adapter/ empty implementation so that users can more easily create annonymous class implementations etc. * IBehaviourRequest is now what previously was IAjaxListener; it serves the same purpose with the difference that it is now fine for users to implement this interface directly (contrairy to IAjaxListener). * IBehaviour extends interfaces IHeaderContributor and IBodyOnloadContributor so that they can make contributions for javascript etc. This is needed for ajax implementations anyway, but could certainly come in handy for a lot of custom behaviours. Other devs: could you please review? Thanks! Eelco On 11/6/05, Ralf Ebert <[EMAIL PROTECTED]> wrote: > 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 > ------------------------------------------------------- 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
