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.
pgpgCBeDWywmk.pgp
Description: PGP signature
