cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject Re: CForms problem
Date Sun, 21 Jan 2007 15:07:25 GMT
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


Mime
View raw message