[jira] [Reopened] (WICKET-2949) Select does not work properly in functional flows e.g. Wizards

["Sven Meier (Reopened) (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sven Meier reopened WICKET-2949:
--------------------------------

      Assignee: Sven Meier  (was: Igor Vaynberg)
    
> Select does not work properly in functional flows e.g. Wizards
> --------------------------------------------------------------
>
>                 Key: WICKET-2949
>                 URL: https://issues.apache.org/jira/browse/WICKET-2949
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket-extensions
>    Affects Versions: 1.4.9
>         Environment: Java 5 Tomcat 5.5.28, Java 6 Tomcat 6.0
>            Reporter: Sven Ludwig
>            Assignee: Sven Meier
>         Attachments: alternative_isSelected_20100719_sludwig.txt
>
>
> When the Select FormComponent for rendering drop-downs is used inside a WizardStep that has a form-submitting back-button with defaultFormProcessing=false, the following effect is possible: Say there are three WizardSteps in a row, and the one with the Select is the middle one. Now say that we first move through the first two steps successfully, with changes to the Model being applied since validation results are ok. Then say we go back to the first step (the Model remaining unchanged during this navigation because in fact all our back-buttons have defaultFormProcessing=false).
> Now comes the problem. If we now from this point go back and forth between the first and the second step, without changing any selections or data, we may not get the result that we would like to see, i.e. that the selected values are kept (re-validated and reapplied to the model, but never changed to other values). But, for example, on going forward to the second step, we may observe the drop-down showing a default value rather than the expected unchanged value.
> I think this happens when the back-button is a form-submitting button with defaultFormProcessing=false that generates raw input on the form, which in case of the Select is a path including the current page version. Then, when we are in step one, we use the next-button to go forward. The Select is being re-rendered and during this phase it checks itself if there is raw input. Indeed, there is, but the path does not match any option, because the page version is now a newer one. Thus, the Select might think it has invalid input, but it does not complain. Instead, it assumes null or empty string as input which leads it to render with the default value being selected.
> (I cannot supply an example for this since we use a copyrighted wizard and i currently have no time to set up an example based on the original wicket-extensions wizard. But it would be great if someone could follow this report and check carefully whether this is really always a problem, and how to fix it. I am going to try a workaround in my case where the Select does "ignore" the page version in the paths. I am not sure yet if there are more problems on the road with this approach.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira