[jira] Commented: (WICKET-1090) clean up raw_input after rendering of form components

["Eelco Hillenius (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WICKET-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536516 ] 

Eelco Hillenius commented on WICKET-1090:
-----------------------------------------

What exactly is that reason then? Why should we hold on to invalid user input? The only case I can imagine is where you want to go to an intermediate page after submitting non-validated input and then go back again and display those same inputs (including the wrong ones) instead of the model values. The price for supporting this use case is the use case I described above, where any arbitrary error in a form submission blocks updating via Ajax of any of the form components in that form. The workaround is to manually clear the input of each of these form components, which is simply horrible.

If you weigh the two use cases against each other, I not only believe mine is stronger, but I also believe that the first one is a hack we don't have to support in the first place. The work around is straightforward: either don't allow navigation to the intermediate screen when there are validation errors (like we do in teachscape btw), or use an model that can be updated even with 'wrong' values (e.g. use strings and do conversion later).

Please share any real use cases this fix broke for you. The case I outlined in this issue is a real one for me.

See also my reply on this thread http://www.nabble.com/Re%3A--jira--Resolved%3A-%28WICKET-1090%29-clean-up-raw_input-after-rendering-of-form-components-tf4657921.html



> clean up raw_input after rendering of form components
> -----------------------------------------------------
>
>                 Key: WICKET-1090
>                 URL: https://issues.apache.org/jira/browse/WICKET-1090
>             Project: Wicket
>          Issue Type: Bug
>    Affects Versions: 1.3.0-beta1, 1.3.0-beta2, 1.3.0-beta3, 1.3.0-beta4
>            Reporter: Eelco Hillenius
>            Assignee: Eelco Hillenius
>             Fix For: 1.3.0-beta5
>
>
> This code doesn't work like it should:
>   super("createUserForm", new CompoundPropertyModel(bean));
>   final TextField passwordField = new TextField("password");
>   passwordField.setOutputMarkupId(true);
>   passwordField.setLabel(new ResourceModel("label.createuser.password"));
>   add(passwordField);
>   add(new AjaxLink("generatePasswordLink") {
>     @Override
>     public void onClick(AjaxRequestTarget target) {
>       bean.setPassword(PasswordGenerator.generate().toString());
>       target.addComponent(passwordField);
>     }
>   });
> It should update the label with the new password, but it doesn't when done after a form submit since it still has the raw_input value it got from that last form submit. There is no reason (as far as I know) to hold on to that value after rendering, so the fix is to clean the raw_input at the end of requests (i.e. onAfterRender).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.