Re: Wicket 1.5 and nested forms
Thank you very much, Thomas, I was struggling with exactly this problem
for a couple of hours yesterday... I think this should be changed back
or at least be configurable in the next versions !
Cheers,
Stefan
Am 13.06.2012 17:14, schrieb Thomas Heigl:
Hello,
In case anyone else is encountering this problem when migrating from 1.4 to
1.5, I solved it by overriding delegateSubmit in my form:
public static enum SubmitOrder {
/** Submit form submitter before forms (1.5 Default) */
OUTSIDE_IN,
/** Submit form submitter after forms (1.4 Default) */
INSIDE_OUT
}
private SubmitOrder submitOrder = SubmitOrder.OUTSIDE_IN;
@Override
protected void delegateSubmit(IFormSubmitter submittingComponent) {
switch (submitOrder) {
case OUTSIDE_IN:
super.delegateSubmit(submittingComponent);
break;
case INSIDE_OUT:
super.delegateSubmit(null);
if (submittingComponent != null) {
submittingComponent.onSubmit();
}
break;
}
}
Cheers,
Thomas
On Wed, May 9, 2012 at 3:07 PM, Thomas Heigl wrote:
Hey Martin,
WICKET-3705 links to https://issues.apache.org/jira/browse/WICKET-1894
which says that this order is changed in 1.4.15
I upgraded to Wicket 1.5 from Wicket 1.4.20 and it still has been working
with 1.4.20.
This is the way how it works in 1.5/6.x. I'm not sure why it is not
documented.
But there are different opinions about it:
https://issues.apache.org/jira/browse/WICKET-3705
I just thought about it some more and I think the new behavior is quite
counter intuitive. For instance my following usecase:
final class CompoundForm extends BaseForm {
public CompoundSearchRequestForm(String id, final IModel model) {
super(id, model);
add(new BaseForm("baseForm", model));
add(new ConfigurationForm("configurationForm", model));
add(new SettingsForm("settingsForm", model));
add(new AjaxButton("save") {
@Override
protected void onSubmit(AjaxRequestTarget target, Form form) {
// do nothing -> delegated to form's onSubmit
}
});
}
@Override
protected void onSubmit() {
super.onSubmit();
listener.saveModel(getModelObject());
}
}
I moved the buttons onSubmit logic to the form's logic to mimic Wicket 1.4
behavior. This works, but the button is now pretty useless and just
triggers a form submit. In the form's onSubmit on the other hand I don't
have (direct) access to the AjaxRequestTarget so I'd have to split
functionality into the two handlers and always think about which order they
are called in.
The problems get harder if you don't have complete control over the nested
form structure. For instance, when you are using the Wizards from
wicket-extensions. They always wrap their contents in a compound form. We
use ajaxified versions of Wizards extensively and the new form submit flow
makes them very hard to use. The next/finish/previous links of the wizard
are now called before any of the actual forms inside the wizard had their
onSubmit handler called. The buttons in fact *replace* the inner form
before it has been submitted and I had to move the wizards state change
logic to onConfigure to make it work again:
@Override
public void onActiveStepChanged(IWizardStep newStep) {
// do nothing -> logic moved to #onConfigure to prevent replacement of
the form before validation of nested forms
}
@Override
protected void onConfigure() {
super.onConfigure();
final IWizardStep activeStep = getActiveStep();
getForm().replace(activeStep.getView(VIEW_ID, this, this));
getForm().replace(activeStep.getHeader(HEADER_ID, this, this));
}
I worked around these problems but I'd greatly prefer a way to configure
the form submit order somewhere. Ideally on the compound form or the ajax
button.
Thomas
On Wed, May 9, 2012 at 1:24 PM, Martin Grigorovwrote:
On Wed, May 9, 2012 at 2:22 PM, Martin Grigorov
wrote:
Hi Thomas,
On Wed, May 9, 2012 at 2:12 PM, Thomas Heigl
wrote:
Hello,
I notices a strange behavior after upgrading to Wicket 1.5. Nested
forms
are submitted in a different order.
I have structures like this:
- Compound Form
-- Subform 1
-- Subform 2
-- Subform 3
- Submit Link/Button for Compound Form
In Wicket 1.4 the order of calls to onSubmit was like this:
1. Subforms
2. Compound Form
3. Submit Link/Button
In multiple locations I had logic in the subforms' onSubmit handlers
that
do cleanup, re-attaching of models to entities etc. before my links
submit
handler is called and persists my model object.
In Wicket 1.5 the submit link's handler that I use for my main logic is
actually called before the subforms:
1. Submit Link
2. Subforms
3. Compound Form
I can fix this by moving all my compound form logic from the
link/buttons
onSubmit handler to the compound form's handler, but wanted to check
first
if this behavior is intentional?
Is this the way to do it in Wicket 1.5?
This is the way how it works in 1.5/6.x. I'm not sure why it is not
documented.
But there are different opinions about it:
https://issues.apache.org/jira/browse/WICKET-3705
WICKET-3705 links to https://issues.
Re: Wicket 1.5 and nested forms
Hello,
In case anyone else is encountering this problem when migrating from 1.4 to
1.5, I solved it by overriding delegateSubmit in my form:
public static enum SubmitOrder {
> /** Submit form submitter before forms (1.5 Default) */
> OUTSIDE_IN,
> /** Submit form submitter after forms (1.4 Default) */
> INSIDE_OUT
> }
>
> private SubmitOrder submitOrder = SubmitOrder.OUTSIDE_IN;
>
@Override
> protected void delegateSubmit(IFormSubmitter submittingComponent) {
> switch (submitOrder) {
> case OUTSIDE_IN:
> super.delegateSubmit(submittingComponent);
> break;
> case INSIDE_OUT:
> super.delegateSubmit(null);
> if (submittingComponent != null) {
> submittingComponent.onSubmit();
> }
> break;
> }
> }
Cheers,
Thomas
On Wed, May 9, 2012 at 3:07 PM, Thomas Heigl wrote:
> Hey Martin,
>
>
>> WICKET-3705 links to https://issues.apache.org/jira/browse/WICKET-1894
>> which says that this order is changed in 1.4.15
>
>
> I upgraded to Wicket 1.5 from Wicket 1.4.20 and it still has been working
> with 1.4.20.
>
> This is the way how it works in 1.5/6.x. I'm not sure why it is not
>> documented.
>> > But there are different opinions about it:
>> > https://issues.apache.org/jira/browse/WICKET-3705
>
>
> I just thought about it some more and I think the new behavior is quite
> counter intuitive. For instance my following usecase:
>
> final class CompoundForm extends BaseForm {
>> public CompoundSearchRequestForm(String id, final IModel model) {
>> super(id, model);
>> add(new BaseForm("baseForm", model));
>> add(new ConfigurationForm("configurationForm", model));
>> add(new SettingsForm("settingsForm", model));
>> add(new AjaxButton("save") {
>> @Override
>> protected void onSubmit(AjaxRequestTarget target, Form form) {
>
> // do nothing -> delegated to form's onSubmit
>> }
>> });
>> }
>> @Override
>> protected void onSubmit() {
>> super.onSubmit();
>> listener.saveModel(getModelObject());
>> }
>> }
>
>
> I moved the buttons onSubmit logic to the form's logic to mimic Wicket 1.4
> behavior. This works, but the button is now pretty useless and just
> triggers a form submit. In the form's onSubmit on the other hand I don't
> have (direct) access to the AjaxRequestTarget so I'd have to split
> functionality into the two handlers and always think about which order they
> are called in.
>
> The problems get harder if you don't have complete control over the nested
> form structure. For instance, when you are using the Wizards from
> wicket-extensions. They always wrap their contents in a compound form. We
> use ajaxified versions of Wizards extensively and the new form submit flow
> makes them very hard to use. The next/finish/previous links of the wizard
> are now called before any of the actual forms inside the wizard had their
> onSubmit handler called. The buttons in fact *replace* the inner form
> before it has been submitted and I had to move the wizards state change
> logic to onConfigure to make it work again:
>
> @Override
>> public void onActiveStepChanged(IWizardStep newStep) {
>> // do nothing -> logic moved to #onConfigure to prevent replacement of
>> the form before validation of nested forms
>> }
>> @Override
>> protected void onConfigure() {
>> super.onConfigure();
>> final IWizardStep activeStep = getActiveStep();
>> getForm().replace(activeStep.getView(VIEW_ID, this, this));
>> getForm().replace(activeStep.getHeader(HEADER_ID, this, this));
>> }
>
>
> I worked around these problems but I'd greatly prefer a way to configure
> the form submit order somewhere. Ideally on the compound form or the ajax
> button.
>
> Thomas
>
> On Wed, May 9, 2012 at 1:24 PM, Martin Grigorov wrote:
>
>> On Wed, May 9, 2012 at 2:22 PM, Martin Grigorov
>> wrote:
>> > Hi Thomas,
>> >
>> > On Wed, May 9, 2012 at 2:12 PM, Thomas Heigl
>> wrote:
>> >> Hello,
>> >>
>> >> I notices a strange behavior after upgrading to Wicket 1.5. Nested
>> forms
>> >> are submitted in a different order.
>> >>
>> >> I have structures like this:
>> >>
>> >> - Compound Form
>> >>> -- Subform 1
>> >>> -- Subform 2
>> >>> -- Subform 3
>> >>> - Submit Link/Button for Compound Form
>> >>
>> >>
>> >> In Wicket 1.4 the order of calls to onSubmit was like this:
>> >>
>> >> 1. Subforms
>> >> 2. Compound Form
>> >> 3. Submit Link/Button
>> >>
>> >> In multiple locations I had logic in the subforms' onSubmit handlers
>> that
>> >> do cleanup, re-attaching of models to entities etc. before my links
>> submit
>> >> handler is called and persists my model object.
>> >>
>> >> In Wicket 1.5 the submit link's handler that I use for my main logic is
>> >> actually called before the subforms:
>> >>
>> >> 1. Submit Link
>> >> 2. Subforms
>> >> 3. Compound Form
>> >>
>> >> I can fix this by moving all my compound form logic from the
>> link/buttons
>> >> onSubmit handler to the compound form's handler, but wanted to check
>> first
>> >> if this behavior is intentional?
>> >> Is this the way to do it in Wicket 1.5?
>> >
>> > This is the way how it works in 1.5/
Re: Wicket 1.5 and nested forms
Hey Martin,
> WICKET-3705 links to https://issues.apache.org/jira/browse/WICKET-1894
> which says that this order is changed in 1.4.15
I upgraded to Wicket 1.5 from Wicket 1.4.20 and it still has been working
with 1.4.20.
This is the way how it works in 1.5/6.x. I'm not sure why it is not
> documented.
> > But there are different opinions about it:
> > https://issues.apache.org/jira/browse/WICKET-3705
I just thought about it some more and I think the new behavior is quite
counter intuitive. For instance my following usecase:
final class CompoundForm extends BaseForm {
> public CompoundSearchRequestForm(String id, final IModel model) {
> super(id, model);
> add(new BaseForm("baseForm", model));
> add(new ConfigurationForm("configurationForm", model));
> add(new SettingsForm("settingsForm", model));
> add(new AjaxButton("save") {
> @Override
> protected void onSubmit(AjaxRequestTarget target, Form form) {
// do nothing -> delegated to form's onSubmit
> }
> });
> }
> @Override
> protected void onSubmit() {
> super.onSubmit();
> listener.saveModel(getModelObject());
> }
> }
I moved the buttons onSubmit logic to the form's logic to mimic Wicket 1.4
behavior. This works, but the button is now pretty useless and just
triggers a form submit. In the form's onSubmit on the other hand I don't
have (direct) access to the AjaxRequestTarget so I'd have to split
functionality into the two handlers and always think about which order they
are called in.
The problems get harder if you don't have complete control over the nested
form structure. For instance, when you are using the Wizards from
wicket-extensions. They always wrap their contents in a compound form. We
use ajaxified versions of Wizards extensively and the new form submit flow
makes them very hard to use. The next/finish/previous links of the wizard
are now called before any of the actual forms inside the wizard had their
onSubmit handler called. The buttons in fact *replace* the inner form
before it has been submitted and I had to move the wizards state change
logic to onConfigure to make it work again:
@Override
> public void onActiveStepChanged(IWizardStep newStep) {
> // do nothing -> logic moved to #onConfigure to prevent replacement of the
> form before validation of nested forms
> }
> @Override
> protected void onConfigure() {
> super.onConfigure();
> final IWizardStep activeStep = getActiveStep();
> getForm().replace(activeStep.getView(VIEW_ID, this, this));
> getForm().replace(activeStep.getHeader(HEADER_ID, this, this));
> }
I worked around these problems but I'd greatly prefer a way to configure
the form submit order somewhere. Ideally on the compound form or the ajax
button.
Thomas
On Wed, May 9, 2012 at 1:24 PM, Martin Grigorov wrote:
> On Wed, May 9, 2012 at 2:22 PM, Martin Grigorov
> wrote:
> > Hi Thomas,
> >
> > On Wed, May 9, 2012 at 2:12 PM, Thomas Heigl
> wrote:
> >> Hello,
> >>
> >> I notices a strange behavior after upgrading to Wicket 1.5. Nested forms
> >> are submitted in a different order.
> >>
> >> I have structures like this:
> >>
> >> - Compound Form
> >>> -- Subform 1
> >>> -- Subform 2
> >>> -- Subform 3
> >>> - Submit Link/Button for Compound Form
> >>
> >>
> >> In Wicket 1.4 the order of calls to onSubmit was like this:
> >>
> >> 1. Subforms
> >> 2. Compound Form
> >> 3. Submit Link/Button
> >>
> >> In multiple locations I had logic in the subforms' onSubmit handlers
> that
> >> do cleanup, re-attaching of models to entities etc. before my links
> submit
> >> handler is called and persists my model object.
> >>
> >> In Wicket 1.5 the submit link's handler that I use for my main logic is
> >> actually called before the subforms:
> >>
> >> 1. Submit Link
> >> 2. Subforms
> >> 3. Compound Form
> >>
> >> I can fix this by moving all my compound form logic from the
> link/buttons
> >> onSubmit handler to the compound form's handler, but wanted to check
> first
> >> if this behavior is intentional?
> >> Is this the way to do it in Wicket 1.5?
> >
> > This is the way how it works in 1.5/6.x. I'm not sure why it is not
> documented.
> > But there are different opinions about it:
> > https://issues.apache.org/jira/browse/WICKET-3705
>
> WICKET-3705 links to https://issues.apache.org/jira/browse/WICKET-1894
> which says that this order is changed in 1.4.15
>
> >
> >>
> >> Cheers,
> >>
> >> Thomas
> >
> >
> >
> > --
> > Martin Grigorov
> > jWeekend
> > Training, Consulting, Development
> > http://jWeekend.com
>
>
>
> --
> 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: Wicket 1.5 and nested forms
On Wed, May 9, 2012 at 2:22 PM, Martin Grigorov wrote: > Hi Thomas, > > On Wed, May 9, 2012 at 2:12 PM, Thomas Heigl wrote: >> Hello, >> >> I notices a strange behavior after upgrading to Wicket 1.5. Nested forms >> are submitted in a different order. >> >> I have structures like this: >> >> - Compound Form >>> -- Subform 1 >>> -- Subform 2 >>> -- Subform 3 >>> - Submit Link/Button for Compound Form >> >> >> In Wicket 1.4 the order of calls to onSubmit was like this: >> >> 1. Subforms >> 2. Compound Form >> 3. Submit Link/Button >> >> In multiple locations I had logic in the subforms' onSubmit handlers that >> do cleanup, re-attaching of models to entities etc. before my links submit >> handler is called and persists my model object. >> >> In Wicket 1.5 the submit link's handler that I use for my main logic is >> actually called before the subforms: >> >> 1. Submit Link >> 2. Subforms >> 3. Compound Form >> >> I can fix this by moving all my compound form logic from the link/buttons >> onSubmit handler to the compound form's handler, but wanted to check first >> if this behavior is intentional? >> Is this the way to do it in Wicket 1.5? > > This is the way how it works in 1.5/6.x. I'm not sure why it is not > documented. > But there are different opinions about it: > https://issues.apache.org/jira/browse/WICKET-3705 WICKET-3705 links to https://issues.apache.org/jira/browse/WICKET-1894 which says that this order is changed in 1.4.15 > >> >> Cheers, >> >> Thomas > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com -- 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: Wicket 1.5 and nested forms
Hi Thomas, On Wed, May 9, 2012 at 2:12 PM, Thomas Heigl wrote: > Hello, > > I notices a strange behavior after upgrading to Wicket 1.5. Nested forms > are submitted in a different order. > > I have structures like this: > > - Compound Form >> -- Subform 1 >> -- Subform 2 >> -- Subform 3 >> - Submit Link/Button for Compound Form > > > In Wicket 1.4 the order of calls to onSubmit was like this: > > 1. Subforms > 2. Compound Form > 3. Submit Link/Button > > In multiple locations I had logic in the subforms' onSubmit handlers that > do cleanup, re-attaching of models to entities etc. before my links submit > handler is called and persists my model object. > > In Wicket 1.5 the submit link's handler that I use for my main logic is > actually called before the subforms: > > 1. Submit Link > 2. Subforms > 3. Compound Form > > I can fix this by moving all my compound form logic from the link/buttons > onSubmit handler to the compound form's handler, but wanted to check first > if this behavior is intentional? > Is this the way to do it in Wicket 1.5? This is the way how it works in 1.5/6.x. I'm not sure why it is not documented. But there are different opinions about it: https://issues.apache.org/jira/browse/WICKET-3705 > > Cheers, > > Thomas -- 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
