Hi Ernesto, Hi Martin,
Thank you very much for your inputs!! Then, I agree on the architecture,
and will generalize this, as part of the upgrade to jQuery UI 1.10.
@Ernesto, glad to read you like the demo app! :) I would like to redesign
it in a little bit more sexy way, but I don't do what I want with the
time... (unfortunately)
What does prevent you to make a demo of wiquery components? Lack of time?
Or is it a technical issue? (your server seems to be IIS7 - with a nice 404
at root by the way)
If this is this second case, and if you do not have your own server
already, maybe can I host your webapp if you need/wish... Feel free to
contact me in PM about this.
Best regards,
Sebastien.
On Tue, Jan 29, 2013 at 10:48 AM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:
> Hi,
>
> On Tue, Jan 29, 2013 at 10:26 AM, Sebastien <seb...@gmail.com> 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>
>
