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
>>
>>
>
