Hi,
On Tue, Jan 29, 2013 at 10:26 AM, Sebastien <[email protected]> wrote:
> Hi Ernesto, Hi Martin,
>
> > IMHO, it would make more sense to have that feature as a behavior instead
> of a panel... that way you are not forcing an inheritance
> For this point, I was not sure whether to make a WebMarkupContainer or a
> Panel that, you are true, force the inheritance.
>
> But actually the main discussion here is... Is it the role of a Behavior to
> handle callbacks or it is the role of a Wicket component to handle these,
> or both.
> I thought about this at the beginning of the project. I wanted to have a
> component oriented API, as Wicket is, and to be the closest as possible in
> term of phylosophy and coding pratice. My conclusion was that, but maybe am
> I wrong, that it is the responsibility of the Component to handle
> callbacks, not the Behavior. (but in another hand, Wicket's Behavior are
> exposing callback sometimes, but mainly Components are doing so)
>
> Sure, it is not a big redesign to make both the Component and the Behavior
> to handle callback, but I would like to be sure it fit Wicket's philosophy.
>
> Ernesto, thanks for your input. I would like other inputs on that subject
> before changing the way the API is designed.
>
>
As Martin already pointed out Behavior approach is more flexible and
reusable... This approach is used all over wicket core. E.g.
public AjaxCheckBox(final String id)
{
this(id, null);
}
public AjaxCheckBox(final String id, final IModel<Boolean> model)
{
super(id, model);
setOutputMarkupId(true);
add(new AjaxFormComponentUpdatingBehavior("click")
{
private static final long serialVersionUID = 1L;
@Override
protected void updateAjaxAttributes(AjaxRequestAttributes attributes)
{
super.updateAjaxAttributes(attributes);
AjaxCheckBox.this.updateAjaxAttributes(attributes);
}
@Override
protected void onUpdate(AjaxRequestTarget target)
{
AjaxCheckBox.this.onUpdate(target);
}
});
}
protected void updateAjaxAttributes(final AjaxRequestAttributes attributes)
{
}
protected abstract void onUpdate(AjaxRequestTarget target);
In your case I would use something like
add(new ResizableBehavior().addEndResizeListener( new IResiseListener() {
public void onResize(AjaxRequestTarget targe....) {
}
}));
This way listening to resize is just a decorator you added to resize
behavior... The JAVAScrip and server side hooks to process resize will only
be added if you register a listener.
Having this behavior implementing ResizablePanel can be left to the
users... or just be an example on your page....
By the way nice demo app! We lack something like that for wiquery! I have
tried to roll out some demo for some wiquery extensions here
http://antiliasoft.com/wiquery-plugins/
But never got to include core UI componets.
--
Regards - Ernesto Reinaldo Barreiro
Antilia Soft
http://antiliasoft.com/ <http://antiliasoft.com/antilia>