[
https://issues.apache.org/jira/browse/WICKET-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sven Ludwig updated WICKET-2949:
--------------------------------
Attachment: (was: alternative_isSelected_20100719_sludwig.txt)
> 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
>
> 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.
