[thelist] Form Submission, Saving Info to Disk

Phil info at webdisplays.com
Thu Jul 19 05:31:45 CDT 2001


At 10:49 PM 7/18/2001 -0700, you wrote:
>Subject: Re: [thelist] Form Submission, Saving Info to Disk
>Reply-To: thelist at lists.evolt.org
>
>Michael Roberto wrote:
>> Scenario:  Ever submit a form, maybe a lengthy one,
>> get an error message on the submission page, go back to the
>> main form page, and find all the information gone?  I'm sure
>> this has happened to most people.
>> 
>> My specific scenario, I was writing a rather long form entry in
>> a textarea, I submitted the form got an error, returned and it
>> was blank.
>
>I haven't seen a reply to this yet.
>
>This is on the edge of hand-waving for me, but I am fairly sure
>that the form contents are not automatically held anywhere that
>you can get hold of.  The program called in the form action is
>the thing that has access to all the form contents.  It's then
>in memory, but can be written to a file, sent in e-mail, or
>used when redisplaying the form
>
>On a registration form for a workshop this year I set it up
>so thar the form was repopulated after showing any error
>messages.  If the form is sucessfully completed, the form
>contents then appear on the ack page in a structured format.
>The workshop has been and gone but I've uploaded a demo
>version of the form if you want to see that it is possible
>to do.  It's at http://www.ppig.org/workshops/evolt-form.lml
>
>As for your first scenario, if you complete part of a form
>but don't submit it (or press any "save" buttons) then click
>to another page, then click a link back to the form, the form
>*will* be empty.  As far as I know, nothing knows what you
>typed in to the form if a program isn't sent any of it.
>
>If you click the Back button to a partially-completed form,
>sometimes the form contents are there and sometimes not for
>depending on the site.  I've suspected that this is to do
>with the way the site's or page's - I'm not really sure.
>
>
>Paola
>
A normal plain html form that can be cached by the visitor will usually
retain any info you type in to it. When you use your back button to 
return to it, the browsers memory should retain this info for you.

Two things may mess this up:

1: Not enough browser memory (RAM not disk cache)
2: no-cache problems. (server or browser)
3: Browser behavior settings.

In the 1st case, having lots of images or a huge form may break this
process, using excessive memory needed for the dynamic data (user
input). This is seldom an issue, but browser settings and behavior are
involved.

If your form contains any SSI includes, such as the date and time
then, when the browser requests (sends) an if-modified-since header
while reloading it, it may get a different document! If the document is
different, the browser will seldom plug stale values back into it.

If your server is set up to force pragma=nocache this may also break
this functionality. 

If the browser is set up to "always check" for a newer version of the 
document, this may also break the dynamic data, especially
if the server insists on sending a unique header (IIS).


There are a number of (simple) ways to preserve form entry contents 
using server side cgi, asp or javascript to reinterpret this data as input 
type=hidden contents written into the custom error report/message 
page!  The error reports submit button (value=Correct) then carries
the users input back to the script for a custom version of the form.

This way, if the cgi script encounters a problem with the data, the 
correction handler can generate/hand the visitor back a "custom" form 
including all the previous input wart(s) should they wish to correct their 
form and resubmit it. This is a vitally important and often overlooked
feature for any sort of interactive sit/board.

Nothing is worse than a "talkback" type of form that asks you to send
comments, then barfs-out for a dumb thing like a missing title, then
wipes out the comments you took the trouble to write! ZDNet have
ruined their sites with just such a badly broken script...

At the very least, a javascript.alert form validator should be offered to
ensure every visitors input is seldom if ever wasted....


Phil Stark
http://www.webdisplays.com






More information about the thelist mailing list