Wicket
  1. Wicket
  2. WICKET-4290

Confusion between a form component's wicket:id and a PageParameter in Wicket 1.5.x

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.0, 1.5.1, 1.5.2, 1.5.3
    • Fix Version/s: 1.5.4, 6.0.0-beta1
    • Component/s: wicket
    • Labels:
      None
    • Environment:
      OS Linux Mint
      Java 1.6

      Description

      A Form has a strange behavior when a component has the same wicket:id than a page parameter.

      To create a Bookmarkable link after a form is submited, setResponsePage is called, and a PageParameter object is given as a parameter :
      PageParameters params = new PageParameters();
      params.add("searchString", searchField.getValue());
      setResponsePage(SomePage.class, params);

      In Wicket 1.5, if "searchString" is also a form-component's wicket:id, the form will only be submitted once :
      searchField.getValue() will always return the first value entered by the user.

      Here's an example :

      public class SearchPanel extends Panel {

      public SearchPanel(String id)

      { super(id); add(new SearchForm("searchForm")); }

      private class SearchForm extends Form<String> {

      private static final long serialVersionUID = 1L;
      private TextField<String> searchField;

      public SearchForm(String id)

      { super(id); searchField = new TextField<String>("searchString", new Model<String>("")); add(searchField); }

      @Override
      public void onSubmit()

      { PageParameters params = new PageParameters(); params.add("searchString", searchField.getValue()); setResponsePage(ListContactsPage.class, params); }

      }
      }

      I tested the same application with Wicket 1.4.17 and it was fine. I only had this problem in Wicket 1.5.2 and 1.5.3.

        Issue Links

          Activity

          Hide
          Emond Papegaaij added a comment -

          A slightly modified version of the patch is applied. PageParameters are no longer rendered in urls for stateful components. StatelessForm and StatelessLink do add the parameters.

          In Wicket 6.0, the old urlFor methods are removed from Component. In 1.5.x they stay, but marked deprecated. Wicket itself no longer uses them.

          Show
          Emond Papegaaij added a comment - A slightly modified version of the patch is applied. PageParameters are no longer rendered in urls for stateful components. StatelessForm and StatelessLink do add the parameters. In Wicket 6.0, the old urlFor methods are removed from Component. In 1.5.x they stay, but marked deprecated. Wicket itself no longer uses them.
          Hide
          Emond Papegaaij added a comment -

          Patch that tries to fix this issue as described by Martin

          Show
          Emond Papegaaij added a comment - Patch that tries to fix this issue as described by Martin
          Hide
          Martin Grigorov added a comment -

          I think the problem lies somewhere else.
          org.apache.wicket.Component#urlFor(RequestListenerInterface) and org.apache.wicket.Component#urlFor(Behavior, RequestListenerInterface) pass PageProvider with a Page instance to IRequestMapper and this way page's parameters are encoded in the url.
          Page's parameters are the parameters in the request when the page is constructed. They are available in any version of the page lifecycle with page.getPageParameters(). I think they shouldn't be encoded in every Link's href, or Form's action, ...

          I think we should change the API for the two methods above to accept PageParameters explicitly. This way the user can decide what parameter to encode in the url.

          In 1.5 the old methods will delegate to the new version and will be deprecated. In 6.0 change the API.

          Show
          Martin Grigorov added a comment - I think the problem lies somewhere else. org.apache.wicket.Component#urlFor(RequestListenerInterface) and org.apache.wicket.Component#urlFor(Behavior, RequestListenerInterface) pass PageProvider with a Page instance to IRequestMapper and this way page's parameters are encoded in the url. Page's parameters are the parameters in the request when the page is constructed. They are available in any version of the page lifecycle with page.getPageParameters(). I think they shouldn't be encoded in every Link's href, or Form's action, ... I think we should change the API for the two methods above to accept PageParameters explicitly. This way the user can decide what parameter to encode in the url. In 1.5 the old methods will delegate to the new version and will be deprecated. In 6.0 change the API.
          Hide
          Emond Papegaaij added a comment -

          The problem is that Form removes the page parameters from the page that is processing the incoming request and then renders a new page using the original page parameters. This causes the request parameters to be rendered in the action url of the form.

          This patch moves the code responsible for removing the conflicting page parameters to onBeforeRender. However, it loses some code that was added for WICKET-3438 (commented lines in the patch). The quickstart that comes with that bug still works correctly though.

          Show
          Emond Papegaaij added a comment - The problem is that Form removes the page parameters from the page that is processing the incoming request and then renders a new page using the original page parameters. This causes the request parameters to be rendered in the action url of the form. This patch moves the code responsible for removing the conflicting page parameters to onBeforeRender. However, it loses some code that was added for WICKET-3438 (commented lines in the patch). The quickstart that comes with that bug still works correctly though.
          Hide
          Victor MONTANER added a comment -

          I just attached a simple, mavenized web project : Zencontact.tar.gz

          I just noticed something : the bug only appears in the home page.
          If you change getHomePage (in the WebApplication class), to return HomePage.class, the problem will not appear.

          Show
          Victor MONTANER added a comment - I just attached a simple, mavenized web project : Zencontact.tar.gz I just noticed something : the bug only appears in the home page. If you change getHomePage (in the WebApplication class), to return HomePage.class, the problem will not appear.
          Hide
          Sven Meier added a comment -

          page parameter is rendered in form action

          Show
          Sven Meier added a comment - page parameter is rendered in form action
          Hide
          Martin Grigorov added a comment -

          Put the example in a quickstart application, please.
          Thanks!

          Show
          Martin Grigorov added a comment - Put the example in a quickstart application, please. Thanks!

            People

            • Assignee:
              Emond Papegaaij
              Reporter:
              Victor MONTANER
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development