You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Philipp Zerelles <ph...@moongate.de> on 2007/01/20 17:14:42 UTC
CForms problem
I found a problem in CForms that seems to be known already but not really addressed.
When I have a CForm and go to a completely different page from there and then come back using the continuation,
my form input fields are cleared because there are no request-parameters and a null value is treated as if the request-parameter was set empty.
The real problem with this is that the validation is triggered as well and errors may be shown although there are none.
This is the part in org.apache.cocoon.forms.formmodel.Field that is responsible for that:
// FIXME: Should we consider only non-null values?
// Although distinguishing an empty value (input present but blank) from a null value
// (input not present in the form) is possible, this distinction is not possible for
// several other kinds of widgets such as BooleanField or MultiValueField. So we keep
// it consistent with other widgets.
//if (newEnteredValue != null) {
readFromRequest(newEnteredValue);
//}
Are the values the form had when last posted not still stored in the widget? After a failed submit I mean.
This code always will overwrite them with empty values if coming back without request-parameters.
What do you think about that?
Re: CForms problem
Posted by Bruno Dumon <br...@outerthought.org>.
On Sat, 2007-01-20 at 18:24 +0100, Philipp Zerelles wrote:
> On Saturday 20 January 2007 18:04, Bruno Dumon wrote:
> > On Sat, 2007-01-20 at 17:14 +0100, Philipp Zerelles wrote:
> > > I found a problem in CForms that seems to be known already but not really addressed.
> > >
> > > When I have a CForm and go to a completely different page from there and then come back using the continuation,
> > > my form input fields are cleared because there are no request-parameters and a null value is treated as if the request-parameter was set empty.
> > > The real problem with this is that the validation is triggered as well and errors may be shown although there are none.
> > >
> > > This is the part in org.apache.cocoon.forms.formmodel.Field that is responsible for that:
> > >
> > > // FIXME: Should we consider only non-null values?
> > > // Although distinguishing an empty value (input present but blank) from a null value
> > > // (input not present in the form) is possible, this distinction is not possible for
> > > // several other kinds of widgets such as BooleanField or MultiValueField. So we keep
> > > // it consistent with other widgets.
> > > //if (newEnteredValue != null) {
> > > readFromRequest(newEnteredValue);
> > > //}
> > >
> > > Are the values the form had when last posted not still stored in the widget? After a failed submit I mean.
> > > This code always will overwrite them with empty values if coming back without request-parameters.
> > >
> > > What do you think about that?
> >
> > Seems normal behaviour to me. If you want to go back to the form, the
> > form shouldn't do a 'form process' cycle, it should simply display the
> > form. For most forms, this can best be done by making a distinction
> > between http GET (display form) and POST (process form) requests.
> >
> > For those cases where a GET makes more sense (e.g. a search form), the
> > parameters should simply be in the URL.
> >
>
> Ok, that makes sense. But currently, the 'form process' cycle is
> started always when coming back to a continuation, even for http GET.
Yes, that seems to be a bit of a problem in flowscript-library. I didn't
study it in detail, but it would probably be possible to add some
property to the forms object to configure whether it should form
processing on post. If it itches you enough, you could look into
patching the Form.js.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: CForms problem
Posted by Philipp Zerelles <ph...@moongate.de>.
On Saturday 20 January 2007 18:04, Bruno Dumon wrote:
> On Sat, 2007-01-20 at 17:14 +0100, Philipp Zerelles wrote:
> > I found a problem in CForms that seems to be known already but not really addressed.
> >
> > When I have a CForm and go to a completely different page from there and then come back using the continuation,
> > my form input fields are cleared because there are no request-parameters and a null value is treated as if the request-parameter was set empty.
> > The real problem with this is that the validation is triggered as well and errors may be shown although there are none.
> >
> > This is the part in org.apache.cocoon.forms.formmodel.Field that is responsible for that:
> >
> > // FIXME: Should we consider only non-null values?
> > // Although distinguishing an empty value (input present but blank) from a null value
> > // (input not present in the form) is possible, this distinction is not possible for
> > // several other kinds of widgets such as BooleanField or MultiValueField. So we keep
> > // it consistent with other widgets.
> > //if (newEnteredValue != null) {
> > readFromRequest(newEnteredValue);
> > //}
> >
> > Are the values the form had when last posted not still stored in the widget? After a failed submit I mean.
> > This code always will overwrite them with empty values if coming back without request-parameters.
> >
> > What do you think about that?
>
> Seems normal behaviour to me. If you want to go back to the form, the
> form shouldn't do a 'form process' cycle, it should simply display the
> form. For most forms, this can best be done by making a distinction
> between http GET (display form) and POST (process form) requests.
>
> For those cases where a GET makes more sense (e.g. a search form), the
> parameters should simply be in the URL.
>
Ok, that makes sense. But currently, the 'form process' cycle is started always when coming back to a continuation, even for http GET.
Re: CForms problem
Posted by Bruno Dumon <br...@outerthought.org>.
On Sat, 2007-01-20 at 17:14 +0100, Philipp Zerelles wrote:
> I found a problem in CForms that seems to be known already but not really addressed.
>
> When I have a CForm and go to a completely different page from there and then come back using the continuation,
> my form input fields are cleared because there are no request-parameters and a null value is treated as if the request-parameter was set empty.
> The real problem with this is that the validation is triggered as well and errors may be shown although there are none.
>
> This is the part in org.apache.cocoon.forms.formmodel.Field that is responsible for that:
>
> // FIXME: Should we consider only non-null values?
> // Although distinguishing an empty value (input present but blank) from a null value
> // (input not present in the form) is possible, this distinction is not possible for
> // several other kinds of widgets such as BooleanField or MultiValueField. So we keep
> // it consistent with other widgets.
> //if (newEnteredValue != null) {
> readFromRequest(newEnteredValue);
> //}
>
> Are the values the form had when last posted not still stored in the widget? After a failed submit I mean.
> This code always will overwrite them with empty values if coming back without request-parameters.
>
> What do you think about that?
Seems normal behaviour to me. If you want to go back to the form, the
form shouldn't do a 'form process' cycle, it should simply display the
form. For most forms, this can best be done by making a distinction
between http GET (display form) and POST (process form) requests.
For those cases where a GET makes more sense (e.g. a search form), the
parameters should simply be in the URL.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org