Forms Retaining Data

[SamMan]

A question came up at work from one of our clients about forms on their
site.

The data from these forms are processed by a PHP script and if all goes
well, a thank you screen appears. Sometimes, when you go back to the form
(by clicking the back button), the data is still there in the form fields.
Other times it is not. The client would like to ensure the data remains, as
they sometimes have multiple submissions to make with similar entries.

There is client-side validation (JavaScript) on the forms, but other than
that, nothing else special about them.

Is there a way to ensure the values in the fields remain on return, or is
this just a quirk in browsers? The most commonly used browsers are IE & NN.

I would include a link to the form in question, but it is a request form for
a gubernatorial service (sent directly to the Gov's office), and I'd hate to
see them receive bogus requests.
Thanks.

--
SamMan
Rip it to reply

[Michael Wilcox]

SamMan wrote:

The client would like to ensure the data remains, as
they sometimes have multiple submissions to make with similar entries.
This is a feature implemented in many browsers, but not all. You cannot
rely on it, since you cannot manipulate the user's browser. However, if
a problem is encountered and an error is found by checking it with PHP,
you should be able to reconstruct the form and fill in the values, all
using PHP. The user shouldn't have to depend on a feature his/her
browser might not have.
There is client-side validation (JavaScript) on the forms, but other than
that, nothing else special about them.

JS validation is ok, but most defiantly should not be relied on.
--
Michael Wilcox, http://mikewilcox.t35.com/

[Alan J. Flavell]

On Fri, 30 Apr 2004, Michael Wilcox wrote:

This is a feature implemented in many browsers, but not all. You cannot
rely on it, since you cannot manipulate the user's browser.
right...
However, if a problem is encountered and an error is found by
checking it with PHP, you should be able to reconstruct the form and
fill in the values, all using PHP. The user shouldn't have to depend
on a feature his/her browser might not have.

Good answer. The same is true for other server-side scripting, though
- it's not limited to PHP: for example the CGI.pm module makes this
quite straightforward in Perl with CGI.

There is client-side validation (JavaScript) on the forms, but other than
that, nothing else special about them.

JS validation is ok, but most defiantly should not be relied on.

Oh, most "defiantly" true ;-) SCNR.

js checks can be useful to both parties as an optional convenience,
but most certainly the submitted parameters must be fully[1] validated
at the server.

[1] where "fully" is defined by the requirements of the application.

hth

[SamMan]

"Alan J. Flavell" <fl*****@ph.gla .ac.uk> wrote in message
news:Pi******** *************** ********@ppepc5 6.ph.gla.ac.uk. ..

On Fri, 30 Apr 2004, Michael Wilcox wrote:

This is a feature implemented in many browsers, but not all. You cannot
rely on it, since you cannot manipulate the user's browser.

right...

However, if a problem is encountered and an error is found by
checking it with PHP, you should be able to reconstruct the form and
fill in the values, all using PHP. The user shouldn't have to depend
on a feature his/her browser might not have.

Good answer. The same is true for other server-side scripting, though
- it's not limited to PHP: for example the CGI.pm module makes this
quite straightforward in Perl with CGI.

There is client-side validation (JavaScript) on the forms, but other than that, nothing else special about them.

JS validation is ok, but most defiantly should not be relied on.

Oh, most "defiantly" true ;-) SCNR.

js checks can be useful to both parties as an optional convenience,
but most certainly the submitted parameters must be fully[1] validated
at the server.

[1] where "fully" is defined by the requirements of the application.

hth

Thanks to both of you for your advice. I kind of thought it was a browser
specific feature.

I agree that JavaScript (JS) isn't generally the best tool, but in this
case, I think it works. The form(s) just takes the form data and sends it to
an e-mail account(s), and is never processed any further (database, etc.).
The JS just basically checks for null values and formatting, so when the
data is sent to the person in charge of the ceremonies, it is clear & makes
sense to them. I also have it so if the end-user has JS disabled, the submit
button is also disabled. I wrote the backend to replace a Pearl script that
our agency was not allowed to alter (working for state agencies is fun!),
and made it hard to manage & alter. Also, the person really in charge of the
forms (and site) is a "veteran" of 10 years in web dev that can't even write
simple JS. I wanted to do all of the validation server-side, but couldn't,
as I had to keep it as simple as possible for the co-worker.

Thanks again!

--
SamMan
Rip it to reply

[Michael Wilcox]

Alan J. Flavell wrote:

Oh, most "defiantly" true ;-) SCNR.
Damn you convenient spell checker! *sigh* It's my own fault, but whatever...

Seems I'm not the only one. In
<http://www.w3.org/TR/AERT#color-contrast> I found, "The rage for color
brightness difference is 125. The range for color difference is 500."
Hmmm, I think the rage should be a little higher ;-)
js checks can be useful to both parties as an optional convenience,
but most certainly the submitted parameters must be fully[1] validated
at the server.

[1] where "fully" is defined by the requirements of the application.

A while ago I found a document saying that forms should be processed so
that users can enter info in a variety of formats and it will be parsed
correctly. The example of a phone number was given, and how so many
formats are used and how users shouldn't be restricted to three little
boxes for the numbers. (I was thinking it was a Korpela article, but I
couldn't find it.)

--
Michael Wilcox, http://mikewilcox.t35.com/

[Michael Wilcox]

SamMan wrote:

I also have it so if the end-user has JS disabled, the submit
button is also disabled.

What good is that? How would I ever submit my form if my JS is off? Or
if I don't even have it?
--
Michael Wilcox, http://mikewilcox.t35.com/

[SamMan]

"Michael Wilcox" <mj************ @yahoo.com> wrote in message
news:c6******** ****@ID-230276.news.uni-berlin.de...

SamMan wrote:

I also have it so if the end-user has JS disabled, the submit
button is also disabled.

What good is that? How would I ever submit my form if my JS is off? Or
if I don't even have it?
--

Because, like I said... the JS is only used to check for null values and/or
formatting of the fields. If JS is disabled, the form can be submitted with
all blank fields. The client does not want this. Just because JS is
disabled, doesn't mean the form submit button won't work.

--
SamMan
Rip it to reply

[SamMan]

"Michael Wilcox" <mj************ @yahoo.com> wrote in message
news:c6******** ****@ID-230276.news.uni-berlin.de...

Alan J. Flavell wrote:

Oh, most "defiantly" true ;-) SCNR.
Damn you convenient spell checker! *sigh* It's my own fault, but

whatever...
Seems I'm not the only one. In
<http://www.w3.org/TR/AERT#color-contrast> I found, "The rage for color
brightness difference is 125. The range for color difference is 500."
Hmmm, I think the rage should be a little higher ;-)

js checks can be useful to both parties as an optional convenience,
but most certainly the submitted parameters must be fully[1] validated
at the server.

[1] where "fully" is defined by the requirements of the application.

A while ago I found a document saying that forms should be processed so
that users can enter info in a variety of formats and it will be parsed
correctly. The example of a phone number was given, and how so many
formats are used and how users shouldn't be restricted to three little
boxes for the numbers. (I was thinking it was a Korpela article, but I
couldn't find it.)

--

That is why I try and use regex whenever possible. :-)

--
SamMan
Rip it to reply

[Michael Wilcox]

SamMan wrote:

Just because JS is disabled, doesn't mean the form submit button won't work.

I'll answer that with a quote from you: "I also have it so if the
end-user has JS disabled, the submit button is also disabled."

Does this mean that if I have my JS off, I can't submit your form?
--
Michael Wilcox, http://mikewilcox.t35.com/

[SamMan]

"Michael Wilcox" <mj************ @yahoo.com> wrote in message
news:c6******** ****@ID-230276.news.uni-berlin.de...

SamMan wrote:

Just because JS is disabled, doesn't mean the form submit button won't

work.
I'll answer that with a quote from you: "I also have it so if the
end-user has JS disabled, the submit button is also disabled."

Does this mean that if I have my JS off, I can't submit your form?
--

Yes... and only because I have coded it so. Without the code I wrote, if the
user has JS disabled, the submit button still functions.

--
SamMan
Rip it to reply