Wicket
  1. Wicket
  2. WICKET-4525

Behavior (which performs a form post) not executed the second time if the form contains a required field (which failed the first time).

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 1.5.6
    • Fix Version/s: None
    • Component/s: wicket
    • Labels:
      None
    • Environment:
      Tested with Tomcat 7 / Jetty 7.5, Firefox 12.0 / Chrome 18.0 (OS: Kubuntu 11.10)

      Description

      • Use case -
        Just to summarize the - real - use case: I have a button which makes the user confirming the form post - before it is being sent - through a dialog box. That means that the button that is displayed does not post the form by itself but delegates the action. To achieve this, an ajax-button (which has setDefaultFormProcessing set to false) opens the dialog box at its onSubmit event. The dialog has an AbstractDefaultAjaxBehavior which will be called on the onclick dialog-confirm-button's event (because it looks like a button but is not a Wicket one). The respond() method of this behavior then attaches a "submit()" javascript command (jQuery, but it can be replaced by a standard javascript here) to the AjaxRequestTarget, which is executed on client side and then the form is submitted over http (non-ajax, then).
      • Symptoms -
        According that the form also has a RequiredTextField (because it makes more sense to send a form that contains form-elements), there is an issue when the user starts by NOT entering a value before posting the form.
        In that case, the form will be sent (for the first time) and the validation will fail as expected. But after that, on successive calls, the form never triggers events anymore (for instance Form#onFormSubmitted()).
        Visually, the form seems to be sent (and the page is refreshed), but it's looks like the behavior script transmitted to the client is not executed (the page is immediately re-rendered after the "Invoking pre-call handler(s)..." step)

      Where it is weird, is that when the user begins by entering a value, send the form, remove the value, resend the form, set a value again, resend, etc. All is working. Just in the case where, at the very first try, no value is set, then the issue appears.

      • Quickstart -
        In the attached quickstart, the "confirm-button" described above has been replaced by a Label which will apply the same technic as describe above.
      1. quickstart.zip
        10 kB
        Sebastien Briquet

        Issue Links

          Activity

          Hide
          Dan Retzlaff added a comment -

          This is related to the fix of WICKET-4286. In the POST, the page's render count is greater than the behavior's request, causing a StalePageException which prevents the form submit.

          Show
          Dan Retzlaff added a comment - This is related to the fix of WICKET-4286 . In the POST, the page's render count is greater than the behavior's request, causing a StalePageException which prevents the form submit.
          Hide
          Dan Retzlaff added a comment -

          Sebastien, if you use an IModel for your attribute modifier, then your javascript will get the latest behavior version, i.e.
          this.add(AttributeModifier.replace("onclick", new AbstractReadOnlyModel<String>() {
          @Override
          public String getObject()

          { return behavior.getCallbackScript().toString(); }

          }));

          Not sure exactly why 1.5.6 is different.

          Show
          Dan Retzlaff added a comment - Sebastien, if you use an IModel for your attribute modifier, then your javascript will get the latest behavior version, i.e. this.add(AttributeModifier.replace("onclick", new AbstractReadOnlyModel<String>() { @Override public String getObject() { return behavior.getCallbackScript().toString(); } })); Not sure exactly why 1.5.6 is different.
          Hide
          Carl-Eric Menzel added a comment -

          Wouldn't the quickstart code (without the model) always point to the old behavior? I'm not too deeply in versioning in 1.5 yet, but superficially this sounds to me like this shouldn't work without the model. Which makes me wonder why it worked before 1.5.6.

          Show
          Carl-Eric Menzel added a comment - Wouldn't the quickstart code (without the model) always point to the old behavior? I'm not too deeply in versioning in 1.5 yet, but superficially this sounds to me like this shouldn't work without the model. Which makes me wonder why it worked before 1.5.6.
          Hide
          Carl-Eric Menzel added a comment -

          And I can confirm that it does work with the model.

          Show
          Carl-Eric Menzel added a comment - And I can confirm that it does work with the model.
          Hide
          Igor Vaynberg added a comment -

          correct. this should not be used without models. urls should be refreshed on every render, otherwise you may have a url that points to an old page version, nevermind the render count, and then all kinds of things will break. it "worked" in 1.5.5 by pure luck or lack of serious testing.

          Show
          Igor Vaynberg added a comment - correct. this should not be used without models. urls should be refreshed on every render, otherwise you may have a url that points to an old page version, nevermind the render count, and then all kinds of things will break. it "worked" in 1.5.5 by pure luck or lack of serious testing.
          Hide
          Sebastien Briquet added a comment -

          Hi Dan, hi Carl (and congratulations !), Hi Igor

          As I mentioned in the mail, I simplify the quickstart (as much I could). And as I comment in the quickstart, the behavior is not used in a "onclick" attribute but rather in a jQuery object. In fact, do not use the AttributeModifier; the real code is much closer to:
          buider.append("function()

          { ").append(behavior.getCallbackScript()).append(" }

          ");

          I am afraid I can not use a Model here. But it's also possible that behavior are not designed to work like this...
          But, in this case, I am afraid (for me) but probably for other developer that may have used this technic...

          Sorry for the confusion,
          Cheers,
          Sebastien.

          Show
          Sebastien Briquet added a comment - Hi Dan, hi Carl (and congratulations !), Hi Igor As I mentioned in the mail, I simplify the quickstart (as much I could). And as I comment in the quickstart, the behavior is not used in a "onclick" attribute but rather in a jQuery object. In fact, do not use the AttributeModifier; the real code is much closer to: buider.append("function() { ").append(behavior.getCallbackScript()).append(" } "); I am afraid I can not use a Model here. But it's also possible that behavior are not designed to work like this... But, in this case, I am afraid (for me) but probably for other developer that may have used this technic... Sorry for the confusion, Cheers, Sebastien.
          Hide
          Igor Vaynberg added a comment -

          for these kinds of cases you have to use wicket's ajax mechanism to do the callback.

          or, wire your function to read the url out of a js variable, and update that js variable with a fresh url on every render.

          Show
          Igor Vaynberg added a comment - for these kinds of cases you have to use wicket's ajax mechanism to do the callback. or, wire your function to read the url out of a js variable, and update that js variable with a fresh url on every render.
          Hide
          Sebastien Briquet added a comment -

          Understood, thank you very much!

          Show
          Sebastien Briquet added a comment - Understood, thank you very much!

            People

            • Assignee:
              Igor Vaynberg
              Reporter:
              Sebastien Briquet
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development