You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Adam Gray <ad...@gmail.com> on 2012/05/16 21:28:11 UTC

AjaxFormChoiceComponentUpdatingBehavior CheckGroup and CheckGroupSelector

Wicket 1.4.20

Use case:  I have a rather large CheckGroup (~250 items) that is
controlling filters to include for an ad hoc reporting solution.  Because
this is so large, the group itself needs to be collapsible.  Easy enough.
 But because it's collapsible, form components in hidden areas won't be
submitted.  So these needs to be pushed to the server as soon as they are
selected.  AjaxFormChoiceComponentUpdatingBehavior works nicely here.

The problem that I'm seeing is that there is no apparent way of knowing
which Check was "click"ed in this behavior.  As such, the only component
that seems to available to add to the AjaxRequestTarget is the CheckGroup
itself.  Even then, this isn't too bad when you're checking individual
items.

The real issue becomes apparent when you throw the CheckGroupSelector into
the mix.  This component goes down the list and calls .click() on each
checkbox.  So you get as many checkgroup refreshes as you have checkboxes.
 Definitely not a problem with typical use cases.  With an extreme use case
like mine, however; it becomes rather unwieldy.

Is it possible to determine which Check was actually clicked and only add
the necessary components to the AjaxRequestTarget to avoid getting
checkgroup postback spam?  Or is there a way that I can customize one of
these classes to somehow batch these updates, a custom CheckGroupSelector
for instance?

Re: AjaxFormChoiceComponentUpdatingBehavior CheckGroup and CheckGroupSelector

Posted by pureza <pu...@gmail.com>.
Nevermind, I think I got it.

--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/AjaxFormChoiceComponentUpdatingBehavior-CheckGroup-and-CheckGroupSelector-tp4641921p4667773.html
Sent from the Users forum mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: AjaxFormChoiceComponentUpdatingBehavior CheckGroup and CheckGroupSelector

Posted by pureza <pu...@gmail.com>.
Martin Grigorov-4 wrote
> I'd write a custom selector that changes the checkboxes's state to
> 'selected' and then uses ajax to make a batch update.

Hi,

Could you expand on this, please? I have the exact same problem.

Thanks,

Luis Pureza

--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/AjaxFormChoiceComponentUpdatingBehavior-CheckGroup-and-CheckGroupSelector-tp4641921p4667765.html
Sent from the Users forum mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: AjaxFormChoiceComponentUpdatingBehavior CheckGroup and CheckGroupSelector

Posted by Adam Gray <ad...@gmail.com>.
That was almost exactly how I ended up solving it last night.  In the end,
the AjaxCheckBox just sets the CheckGroup's model object such that it's all
selected then adds the group to the AjaxRequestTarget just the once.  That
worked nicely for reducing the roundtrips.

As an aside, I noticed that wicket:enclosure is quite a lot slower than
setting individual component visibility, at least in my case.  I was really
just making sure the Label was hidden its input was hidden.  It'd be really
nice if <label wicket:for=""> could link visibility, but not necessary.
 Just something I happened to notice when rendering a large ListView of
Checks and Labels.

On Thu, May 17, 2012 at 8:08 AM, Martin Grigorov <mg...@apache.org>wrote:

> Hi,
>
> Can org.apache.wicket.ajax.markup.html.form.AjaxCheckBox help for your
> case ?
> I'd write a custom selector that changes the checkboxes's state to
> 'selected' and then uses ajax to make a batch update.
>
> On Wed, May 16, 2012 at 9:28 PM, Adam Gray <ad...@gmail.com> wrote:
> > Wicket 1.4.20
> >
> > Use case:  I have a rather large CheckGroup (~250 items) that is
> > controlling filters to include for an ad hoc reporting solution.  Because
> > this is so large, the group itself needs to be collapsible.  Easy enough.
> >  But because it's collapsible, form components in hidden areas won't be
> > submitted.  So these needs to be pushed to the server as soon as they are
> > selected.  AjaxFormChoiceComponentUpdatingBehavior works nicely here.
> >
> > The problem that I'm seeing is that there is no apparent way of knowing
> > which Check was "click"ed in this behavior.  As such, the only component
> > that seems to available to add to the AjaxRequestTarget is the CheckGroup
> > itself.  Even then, this isn't too bad when you're checking individual
> > items.
> >
> > The real issue becomes apparent when you throw the CheckGroupSelector
> into
> > the mix.  This component goes down the list and calls .click() on each
> > checkbox.  So you get as many checkgroup refreshes as you have
> checkboxes.
> >  Definitely not a problem with typical use cases.  With an extreme use
> case
> > like mine, however; it becomes rather unwieldy.
> >
> > Is it possible to determine which Check was actually clicked and only add
> > the necessary components to the AjaxRequestTarget to avoid getting
> > checkgroup postback spam?  Or is there a way that I can customize one of
> > these classes to somehow batch these updates, a custom CheckGroupSelector
> > for instance?
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: AjaxFormChoiceComponentUpdatingBehavior CheckGroup and CheckGroupSelector

Posted by Martin Grigorov <mg...@apache.org>.
Hi,

Can org.apache.wicket.ajax.markup.html.form.AjaxCheckBox help for your case ?
I'd write a custom selector that changes the checkboxes's state to
'selected' and then uses ajax to make a batch update.

On Wed, May 16, 2012 at 9:28 PM, Adam Gray <ad...@gmail.com> wrote:
> Wicket 1.4.20
>
> Use case:  I have a rather large CheckGroup (~250 items) that is
> controlling filters to include for an ad hoc reporting solution.  Because
> this is so large, the group itself needs to be collapsible.  Easy enough.
>  But because it's collapsible, form components in hidden areas won't be
> submitted.  So these needs to be pushed to the server as soon as they are
> selected.  AjaxFormChoiceComponentUpdatingBehavior works nicely here.
>
> The problem that I'm seeing is that there is no apparent way of knowing
> which Check was "click"ed in this behavior.  As such, the only component
> that seems to available to add to the AjaxRequestTarget is the CheckGroup
> itself.  Even then, this isn't too bad when you're checking individual
> items.
>
> The real issue becomes apparent when you throw the CheckGroupSelector into
> the mix.  This component goes down the list and calls .click() on each
> checkbox.  So you get as many checkgroup refreshes as you have checkboxes.
>  Definitely not a problem with typical use cases.  With an extreme use case
> like mine, however; it becomes rather unwieldy.
>
> Is it possible to determine which Check was actually clicked and only add
> the necessary components to the AjaxRequestTarget to avoid getting
> checkgroup postback spam?  Or is there a way that I can customize one of
> these classes to somehow batch these updates, a custom CheckGroupSelector
> for instance?



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org