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