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 tho...@umschalt.com 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 BaseFormExample {
public CompoundSearchRequestForm(String id, final IModelExample 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 mgrigo...@apache.orgwrote:
On Wed, May 9, 2012 at 2:22 PM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi Thomas,
On Wed, May 9, 2012 at 2:12 PM, Thomas Heigl tho...@umschalt.com
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
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 Heigltho...@umschalt.com 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 BaseFormExample {
public CompoundSearchRequestForm(String id, final IModelExample 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 Grigorovmgrigo...@apache.orgwrote:
On Wed, May 9, 2012 at 2:22 PM, Martin Grigorovmgrigo...@apache.org
wrote:
Hi Thomas,
On Wed, May 9, 2012 at 2:12 PM, Thomas Heigltho...@umschalt.com
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:
Re: Wicket 1.5 and nested forms
Hi Thomas, On Wed, May 9, 2012 at 2:12 PM, Thomas Heigl tho...@umschalt.com 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
Re: Wicket 1.5 and nested forms
On Wed, May 9, 2012 at 2:22 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi Thomas, On Wed, May 9, 2012 at 2:12 PM, Thomas Heigl tho...@umschalt.com 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
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 BaseFormExample {
public CompoundSearchRequestForm(String id, final IModelExample 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 mgrigo...@apache.orgwrote:
On Wed, May 9, 2012 at 2:22 PM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi Thomas,
On Wed, May 9, 2012 at 2:12 PM, Thomas Heigl tho...@umschalt.com
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
