Hi,
For that same reason, I'd like to keep ajaxhandlers behaviours
like now in cvs HEAD. Furthermore I prefer behaviour listeners to ajax
listeners because that is conceptually right. Practually, I don't
forsee any other implementation than ajax, but conceptually, there is
no reason why this couldn't be.
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. Having an implementation independent name
is all right, but I think the "to have a behaviourlistener you have
to be a behaviour" is wrong.
several small issues). Furthermore, this is exactly what I mean when I
say I don't want behaviours to evolve to something similar of
components. If we really want to support things like this, we would
need a formalized event model, we would need to sync multiple
component/ behaviours trees, etc.
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.
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).
I think instead of opening up the box of pandora (as some comitters
are afraid of we already did with behaviours) even further
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'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). 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.
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 :)
, we should go from use case to use case from here. If you have a
usecase you want
to see implemented, but is impossible to do with Wicket now, we'll go
on with this discussion (and of course patches help ;)).
I think I can provide valid use cases for most of the things I
propose, so I have absolutely no problem with 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
