> 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.
>
Actually, I think that would go too far in this stage. I like the
behaviour thing because it is conceptually sound, and it finally gives
AttributeModifiers a good place to fit in. What I don't want however,
is to let evolve the behaviours to things that are very close to
actual components. If we go too far with this, it would just be too
easy to make a mess out of it, and there wouldn't be a clear
distinction between what a component should be and a behaviour should
be. 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.
> 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)
Binding/ adding comes down to the same thing, as ultimately components
would be the container right? Unless e.g. you want to store it on a
page level, which would break encapsulation (and would introduce
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.
> - 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.
Actually, things like that have been possible with AttributeModifiers
for a long time now.
/**
* Gets the value that should replace the current attribute value. This
* gives users the ultimate means to customize what will be used as the
* attribute value. For instance, you might decide to append the
replacement
* value to the current instead of just replacing it as is Wicket's
default.
*
* @param currentValue
* The current attribute value. This value might be null!
* @param replacementValue
* The replacement value. This value might be null!
* @return The value that should replace the current attribute value
*/
protected String newValue(final String currentValue, final String
replacementValue)
{
return replacementValue;
}
>
> I would like to implement these things without breaking anything once
> the behaviour api is kind of stable/accepted... Any ideas about that?
>
I think instead of opening up the box of pandora (as some comitters
are afraid of we already did with behaviours) even further, 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 ;)).
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
