[ https://issues.apache.org/jira/browse/WICKET-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sven Ludwig updated WICKET-2949: -------------------------------- Environment: Java 5 Tomcat 5.5.28, Java 6 Tomcat 6.0 (was: Java 5 Tomcat 5.5.28) > 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 > 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. - You can reply to this email to add a comment to the issue online.