You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Johan Compagner <jc...@gmail.com> on 2007/10/20 15:03:17 UTC
Re: [jira] Resolved: (WICKET-1090) clean up raw_input after rendering of form components
i hope now that nobody is using the form as a tmp holding area which
we told people they could do from version 1.1 or something !
temp storage like go from page x to y then back again. i gues that
still works? we only clear the pages that are really rendered again?
or all of them that are used in a request?
On 10/20/07, Eelco Hillenius (JIRA) <ji...@apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/WICKET-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Eelco Hillenius resolved WICKET-1090.
> -------------------------------------
>
> Resolution: Fixed
>
> > 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.
>
>
Re: [jira] Resolved: (WICKET-1090) clean up raw_input after rendering of form components
Posted by Matej Knopp <ma...@gmail.com>.
Just to show you one of the thing your fix broke:
Go to the form input applicaiton.
Enter invalid input in some fields.
Submit form.
Refresh page.
your input is gone. Now as an user for such app this behavior would
really piss me of. As for the original problem, I believe the proper
solution is to call modelChanged() when you need to set value on field
with intermediate input. Is it such a big deal? Heck, you can even put
it to visitor. Or we could have such method in form that invokes this
on all children. It would be 5 lines of code and it wouldn't break
every wicket application out there.
-Matej
On 10/21/07, Matej Knopp <ma...@gmail.com> wrote:
> On 10/21/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > On 10/21/07, Matej Knopp <ma...@gmail.com> wrote:
> > > Hold on, the raw input _must_ be preserved after rendering. Where else
> > > would we keep invalid input?
> >
> > Why do we need to keep invalid input after rendering? Any such input
> > is already consumed for feedback messages, and the renders should
> > either render their model values if they did not get new input, or
> > render *new* input that may have been submitted.
> And what happens on page refresh? You just lose user input?
> >
> > > The code also doesn't make sense - there
> > > is no reason why it shouldn't work, except when the page was submitted
> > > before the render and the submit was not validated.
> >
> > But that is exactly my problem! So any form submit that doesn't
> > validate subsequently holds back updating of any of the form
> > components via Ajax like my example does, because the inputs aren't
> > cleared (whether they are valid or not).
> >
> > > Am I missing something?
> >
> > Am I? What are the disadvantages of my fix exactly? I think the
> > per-request scope is just right, and anything that should be persisted
> > over multiple requests should be done via model updates.
> How comes? We have this behaviors since 1.1 and suddenly is wrong?
> There are lot of cases when you have only part of form that is valid
> input and need you to persist it during requests. I have a lot of
> intermediate browse pages and all browse dialogs are done with button
> that has setDefaultFormProcessing(false). Now your change just
> silently broke all those dialogs.
> >
> > Eelco
> >
>
Re: [jira] Resolved: (WICKET-1090) clean up raw_input after rendering of form components
Posted by Matej Knopp <ma...@gmail.com>.
On 10/21/07, Eelco Hillenius <ee...@gmail.com> wrote:
> On 10/21/07, Matej Knopp <ma...@gmail.com> wrote:
> > Hold on, the raw input _must_ be preserved after rendering. Where else
> > would we keep invalid input?
>
> Why do we need to keep invalid input after rendering? Any such input
> is already consumed for feedback messages, and the renders should
> either render their model values if they did not get new input, or
> render *new* input that may have been submitted.
And what happens on page refresh? You just lose user input?
>
> > The code also doesn't make sense - there
> > is no reason why it shouldn't work, except when the page was submitted
> > before the render and the submit was not validated.
>
> But that is exactly my problem! So any form submit that doesn't
> validate subsequently holds back updating of any of the form
> components via Ajax like my example does, because the inputs aren't
> cleared (whether they are valid or not).
>
> > Am I missing something?
>
> Am I? What are the disadvantages of my fix exactly? I think the
> per-request scope is just right, and anything that should be persisted
> over multiple requests should be done via model updates.
How comes? We have this behaviors since 1.1 and suddenly is wrong?
There are lot of cases when you have only part of form that is valid
input and need you to persist it during requests. I have a lot of
intermediate browse pages and all browse dialogs are done with button
that has setDefaultFormProcessing(false). Now your change just
silently broke all those dialogs.
>
> Eelco
>
Re: [jira] Resolved: (WICKET-1090) clean up raw_input after rendering of form components
Posted by Eelco Hillenius <ee...@gmail.com>.
On 10/21/07, Eelco Hillenius <ee...@gmail.com> wrote:
> On 10/21/07, Matej Knopp <ma...@gmail.com> wrote:
> > Hold on, the raw input _must_ be preserved after rendering. Where else
> > would we keep invalid input?
>
> Why do we need to keep invalid input after rendering? Any such input
> is already consumed for feedback messages, and the renders should
> either render their model values if they did not get new input, or
> render *new* input that may have been submitted.
>
> > The code also doesn't make sense - there
> > is no reason why it shouldn't work, except when the page was submitted
> > before the render and the submit was not validated.
>
> But that is exactly my problem! So any form submit that doesn't
> validate subsequently holds back updating of any of the form
> components via Ajax like my example does, because the inputs aren't
> cleared (whether they are valid or not).
>
> > Am I missing something?
>
> Am I? What are the disadvantages of my fix exactly? I think the
> per-request scope is just right, and anything that should be persisted
> over multiple requests should be done via model updates.
>
Btw, let's keep the discussion with the JIRA issue.
Eelco
Re: [jira] Resolved: (WICKET-1090) clean up raw_input after rendering of form components
Posted by Eelco Hillenius <ee...@gmail.com>.
On 10/21/07, Matej Knopp <ma...@gmail.com> wrote:
> Hold on, the raw input _must_ be preserved after rendering. Where else
> would we keep invalid input?
Why do we need to keep invalid input after rendering? Any such input
is already consumed for feedback messages, and the renders should
either render their model values if they did not get new input, or
render *new* input that may have been submitted.
> The code also doesn't make sense - there
> is no reason why it shouldn't work, except when the page was submitted
> before the render and the submit was not validated.
But that is exactly my problem! So any form submit that doesn't
validate subsequently holds back updating of any of the form
components via Ajax like my example does, because the inputs aren't
cleared (whether they are valid or not).
> Am I missing something?
Am I? What are the disadvantages of my fix exactly? I think the
per-request scope is just right, and anything that should be persisted
over multiple requests should be done via model updates.
Eelco
Re: [jira] Resolved: (WICKET-1090) clean up raw_input after rendering of form components
Posted by Matej Knopp <ma...@gmail.com>.
Hold on, the raw input _must_ be preserved after rendering. Where else
would we keep invalid input? The code also doesn't make sense - there
is no reason why it shouldn't work, except when the page was submitted
before the render and the submit was not validated.
Am I missing something?
-Matej
On 10/20/07, Johan Compagner <jc...@gmail.com> wrote:
> i hope now that nobody is using the form as a tmp holding area which
> we told people they could do from version 1.1 or something !
> temp storage like go from page x to y then back again. i gues that
> still works? we only clear the pages that are really rendered again?
> or all of them that are used in a request?
>
> On 10/20/07, Eelco Hillenius (JIRA) <ji...@apache.org> wrote:
> >
> > [
> > https://issues.apache.org/jira/browse/WICKET-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> > ]
> >
> > Eelco Hillenius resolved WICKET-1090.
> > -------------------------------------
> >
> > Resolution: Fixed
> >
> > > 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.
> >
> >
>