> Well, that isn't very far from what I think... I only say that a
> behaviour should be no listener at all by default but can register
> listeners at the component.
A behaviour is not a listener by default. You have to additionally
implement the IBehaviourListener interface.
Having an implementation independent name
> is all right, but I think the "to have a behaviourlistener you have
> to be a behaviour" is wrong.
I disagree. I see no reason for the decoupling of the two; it would
make it harder to implement and conceptually less strong imo.
> Well, I'm also happy with adding a behaviour to each related
> component and link the behaviours together for interaction. It's just
> that this is not the greatest way to express things going on
> "between" components.
If we can find better ways for inter-component/ inter-behaviour
interactions, and they would be realy elegant, that would be good.
What I don't want however, is just open up the API to give maximum
flexibility while we don't even know what the best way to handle
things are is yet.
>
> > Actually, things like that have been possible with AttributeModifiers
> > for a long time now.
> Well, "resolving attribute conflicts" can include more than changing
> the attribute itself. if you have onclick="alert('test');" and
> onclick="alert('test2');" you can only resolve that by creating a
> javascript function, a thing a attributemodifier cannot do (I think).
AttributeModifiers couldn't do that. Behaviours/ custom attribute
modifiers can now do this too.
> Well, the behaviour thing was an idea. I provided use cases for this
> kind of extension points which are very valid from my point of view.
I was more thinking about specific, conrete use cases instead of general ideas.
> I'm too new to Wicket development to know the complete framework nor
> the ideas the comitters have according to extensibility (except they
> like to restrict it to have no problems with changing details behind
> the scenes).
Actually, that's not the point. It's a good thing to hide
implementation details for many reasons. We have been able to change
implementation details in Wicket without too much impact a lot of
times for sure, so I'm thankful for Jonathan doing this right from the
start. But also, we want to keep the conceptual surface small in order
to keep Wicket relatively easy to use, and we want to understand use
cases first so that we can hopefully agree on the best way to support
them instead of providing a lot of flexibility and letting users
wonder which of the zillion ways they should follow. That's the goal.
The world isn't pefect and nor are we, but we strive to deliver a
framework with a sound API.
> And actually I'm wondering how I can get into this if
> there is no public discussion but just "some comitters are afraid". I
> would love to discuss these things.
We like to discuss these things too :) I just wanted to make very
clear that we don't want to deliver maximum flexibility at the cost of
our other API goals.
> One of my central points was: "I want to add ajax behaviour to
> standard components without changing the component itself". From my
> point of view, this is a reasonable intention. But it also means that
> something (extensible) is needed which is "not a component". If this
> kind of extensibility is considered as "box of pandora" I would like
> to hear some discussion actually :)
The box of pandora is that it is forseable that we'll get questions
like: I want other lifecycle methods implemented, I want to be able to
let them render too, I want them to have models, etc. If we are not
consious about it, they could end up being horrible things which break
the general goal of simplicity we have for Wicket.
> I think I can provide valid use cases for most of the things I
> propose, so I have absolutely no problem with that.
Great, looking forward to them :)
Eelco
-------------------------------------------------------
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
