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<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 BaseForm<Example>  {
public CompoundSearchRequestForm(String id, final IModel<Example>  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.org>wrote:

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



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

Reply via email to