Hi,
* 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.
I had the same idea first but decided not to make it an interface
because this would have forced the methods to be public. Some kind of
interaction can be strictly between component and behaviour and
protected methods allow you to protect these details... But I think
that can be a two-edged sword and probably it's better to do it using
an interface.
* 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).
Well, I tried to refactor the AjaxHandler to be a behaviour as well
but at some point I had to make too many changes to do it myself...
So this works now as well as thought, great! Although I think
IBehaviourListener should be called IAjaxListener though because a
behavior is something that happens on the server side while the
ajaxlistener is for handling responses which are generated by client
side javascript (which are generated by behaviour) - and thats called
ajax. I'm also unsure if the registering for ajax listeners (not
handlers!) shouldn't be separate from behaviours (these can add
listeners of course), because what if one behaviour needs two
different ajax listeners?
This is a bit mixed in the same way the ajaxhandler was, I would like
a more clean separation like in: a behaviour is no listener till he
decides to implement the interface and register itself at the component.
Other devs: could you please review?
I'm happy with it as far as I see :)
Some ideas I already had in my head for the case the behaviors get
accepted:
- I want a behaviour to be able to request other behaviours for a
component (use case: a AjaxBehaviour using a
JavaScriptEventAttributeModifier to get the onXxx="" event into the
markup). I would prefer not calling add(...), because if the original
behaviour gets removed I want the dependant behaviours go away as
well. Same goes probably for ajaxlistener if the more separated way
is gone as mentioned above.
- I would like to try to make behaviours bind to the component
instead of the behaviour added to the component. this makes
behaviours work like listeners a bit more, they can register for
component events (use case: many client side behaviours are
interconnected between more than one component; binding to multiple
components could be handled the other way round a better way)
- I want behaviours to be able to work together with other behaviours
which are attached to the component (use case: two attributemodifiers
want to add a style attribute - I want themselfes to resolve that if
possible)
- I want to implement a StyleAttributeModifier and a
JavaScriptAttributeModifier which allows easy manipulation of style /
js attributes and clever handling / smart exceptions when conflicts
occur.
I would like to implement these things without breaking anything once
the behaviour api is kind of stable/accepted... Any ideas about that?
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
