Martijn Dashorst a écrit :
On 4/13/07, Vincent Demay <[EMAIL PROTECTED]> wrote:
What about a simple Behavior, I think behavior is easier to use for the
end user
class onRefreshAnimationBehavior extends AbstractBehavior{
onRendered(){
if(AjaxRequestTarget){
target.prependJavascript(getFromEffect())
target.appendJavascript(getToEffect());
}
}
CharSequence getFromEffect();
CharSequance getToEffect();
}
so user can extend it, ie
onRefreshAnimatedClassBehavior(fromClass, toClass)
in order to do
component.add(new onRefreshAnimatedClassBehavior("yellow", "default"));
This is creating a complete slew of new behaviors. I don't like that.
We have to implement it in a way, that we don't increase the API too
much.
I'm not sure it need to create a huge set of behavior, just one (or 2)
with a default implementation for getFromEffect and getToEffect
If user want to create its own one he should extend it and write its own
implementation.
I think behavior is the less intrusive way to integrate some "refresh
decorator", moreover behavior encapsulate all stuffs concerning effect
in a simple class and do not need to a new Api to generate effects which
should be used to append JS on a ajaxRequestTarget - (if api exists it
is an inner one).
What Al coined seems like a nice option (needs a bit polish imo, but
the basic idea seems sound), *if* we want to support animation as a
core functionality. This would increase the API for the
AjaxRequestTarget. Couldn't we implement it in a less intrusive way,
so that the scriptaculous/dojo/moo fans can plug into our animation
aware target?
Martijn
