Re: AjaxFormChoiceComponentUpdatingBehavior CheckGroup and CheckGroupSelector
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AjaxFormChoiceComponentUpdatingBehavior CheckGroup and CheckGroupSelector
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AjaxFormChoiceComponentUpdatingBehavior CheckGroup and CheckGroupSelector
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 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 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 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-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: AjaxFormChoiceComponentUpdatingBehavior CheckGroup and CheckGroupSelector
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 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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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?