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

[Darin McGrew]

"Sherm Pendley" <sp******@dot-app.org> wrote:

What happens when a user hits return? A button isn't the only way to
submit a form...

SamMan <sa*@psfdevri p-it.com> wrote: Nothing. The form is not submitted.

Let's try again.

What happens if the user submits the form anyway, even though you've tried
to prevent them from doing so?

Perhaps they use normal browser functions. Hitting the Enter key is one way
that browsers allow the user to submit a form without the submit button.

Perhaps they edit your form, add a submit button, and submit the edited
version of the form. It isn't hard to do if you know what you're doing.

And given the relationship between your site and the government, you may be
legally required to provide non-JavaScript functionality.
--
Darin McGrew, mc****@stanford alumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp. com, http://www.HTMLHelp.com/

"Warning: Dates in the calendar are closer than they appear."

[Stephen Poley]

On Sat, 01 May 2004 01:57:27 GMT, "SamMan" <sa*@psfdevri p-it.com> wrote:

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

SamMan wrote:

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

That's a poor choice. The user's browser may not have JS,

<snip>

What browser does not have JS? On my workstation, I have IE, NN (4 & 7),
Mozilla, Opera... all of them have JS, and it is enabled by default. This is
on a PC. I have also tested on Mac IE and Safari, both with JS.

Perhaps you would consider the points raised in
http://www.xs4all.nl/~sbpoley/webmatters/whatnojs.html

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/

[SamMan]

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

SamMan wrote:

I agree that it would be better to do all error checking on the server, but like I have stated before, I have to accommodate the developer who has
little to no experience in JS, let alone anything that happens on the server side. They are the one who has "official" control over the site, and as
such, things must be done to make it easier for them... one of the pitfalls of working for a government agency.
Could you write the necessary PHP code? Would "they" allow it?

No, I have inquired already...

And since you brought up the government, I'll quote a government
document. Section 508 <http://www.access-board.gov/sec508/guide/act.htm>
requires all government webpages to comply with its regulations, one of
which reads, "When electronic forms are designed to be completed
on-line, the form shall allow people using assistive technology to
access the information, field elements, and functionality required for
completion and submission of the form, including all directions and
cues." Most assistive technologies are incapable of rendering JS, and
they therefore render what is in the noscript element. At your page,
this is their only option, and they can never submit the form, which
contradicts these regulations.

A sightless person has tested the forms and was able to fill out & submit
them.

[SamMan]

"Darin McGrew" <mc****@stanfor dalumni.org> wrote in message
news:c6******** **@blue.rahul.n et...

"Sherm Pendley" <sp******@dot-app.org> wrote:

What happens when a user hits return? A button isn't the only way to
submit a form...

SamMan <sa*@psfdevri p-it.com> wrote:

Nothing. The form is not submitted.

Let's try again.

What happens if the user submits the form anyway, even though you've tried
to prevent them from doing so?

Perhaps they use normal browser functions. Hitting the Enter key is one

way that browsers allow the user to submit a form without the submit button.

Perhaps they edit your form, add a submit button, and submit the edited
version of the form. It isn't hard to do if you know what you're doing.

And given the relationship between your site and the government, you may be legally required to provide non-JavaScript functionality.
--

If the user succeeds in submitting a form, a blank submission would be sent
to an e-mail address and ignored. I understand you're point, but if a person
goes to the trouble of editing the form to submit a blank one, all they will
have succeeded at is sending a form that will be ignored.

You do bring up a good point about non- JS functionality that I can use in
my defense of doing the error checking backend.

--
SamMan
Rip it to reply

[Alan J. Flavell]

On Sat, 1 May 2004, SamMan wrote:

If JS is disabled, the form can be submitted with all blank fields.
With respect: reading the thread before and after this posting of
yours, you seem to have contradicted yourself several times on that
point. I'm no longer sure quite -what- you're claiming will happen.

But, as I've said before, and as others have said on this thread, it's
essential for a server-side process to cope with -any- input that gets
thrown as it. There's no way - repeat: NO way - that anything in your
HTML or js can protect the server against defective or plain malicious
inputs, and if the server-side process then does something harmful,
that's your fault (as developer of the procedure) for letting it.

So, js verification of the data can be a useful optional -extra- (to
avoid wasteful submission/rejection cycles), but must NEVER be
considered as an alternative to server-side validation of the input.
The client does not want this.
What the client wants, and what the WWW will do, are not necessarily
the same thing. It's our job as developers to resolve such
inconsistences ;-}
Just because JS is disabled, doesn't mean the form submit button
won't work.

I'm convinced that you also said the opposite. But no matter: your
server-side script can get invoked by anyone with a mind to do it, no
matter how hard you try to stop it in your HTML.

And I'd have to agree with those who pointed out the implications of
the WAI requirements if this is, for example, government work.

good luck with the project

[Brian]

Alan J. Flavell wrote:

On Sat, 1 May 2004, SamMan wrote:

The client does not want this.

What the client wants, and what the WWW will do, are not necessarily
the same thing. It's our job as developers to resolve such
inconsistences ;-}

That's another of those nuggets that belongs in a faq or something. Well
said!

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

[Michael Wilcox]

SamMan wrote:

A sightless person has tested the forms and was able to fill out & submit
them.

*One* person trying the site with *one* browser doesn't mean everyone
will have the same experience. Did this person use an assistive
technology, as required by Section 508? Did they accomplish it without
JS and without the direction of someone else?

(BTW, I never wished to turn this into a flame thing, so I'll try to
keep out the maliciousness as much as possible.)
--
Michael Wilcox, http://mikewilcox.t35.com/

[Harlan Messinger]

Michael Wilcox <mj************ @yahoo.com> wrote:

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.

I hate to say it, but this is a case where pop-up windows may be
necessary--unless someone can come up with another way to handle a
form complicated enough to justify inclusion of Help links. If a user
has partially completed a form when he clicks a Help link, then after
the Help page has loaded in his browser, and he has hit the Back
button to return to his form, I guarantee that he will be annoyed if
his previous entries have all disappeared.

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.

[Michael Wilcox]

Harlan Messinger wrote:

I hate to say it, but this is a case where pop-up windows may be
necessary
Well, if PHP is available, popups are hardly necessary. I wish I could
think of a good solution when PHP isn't available, but a well designed
site should have to rely on potentially missing features.
unless someone can come up with another way to handle a
form complicated enough to justify inclusion of Help links.

I don't think the form in question is complicated (although I haven't
seen it), but I think the question is whether or not you could submit it.
--
Michael Wilcox, http://mikewilcox.t35.com/

[Michael Wilcox]

SamMan wrote:

A sightless person has tested the forms and was able to fill out & submit
them.

I forgot to add: Since a user with an assistive technology might fill in
the entire form, then find out he/she can't even submit it, why put put
a warning in noscript tags that this user won't be able to submit the
data. (Mean rant: Why would you do this? Why can't you just let a few
bad forms go through? Most people will probably fill them in regardless
of what browser they are using.)
--
Michael Wilcox, http://mikewilcox.t35.com/