Automated forms

Alastair Aitken CLMS <ZPALASTAIR@CLUSTER.NORTH-LONDON.AC.UK>

Mail folder: WWW Talk Apr 94-present
Next message: Paul "S." Wain: "Re: Fast HTTP - a hyper-text transfer protocol for tommorows networks."
Previous message: Yee-Hsiang Chang: "subscribe"

Errors-To: listmaster@www0.cern.ch
Date: Thu, 30 Jun 1994 11:26:43 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9406300923.AA16957@dxmint.cern.ch>
Errors-To: listmaster@www0.cern.ch
Reply-To: ZPALASTAIR@CLUSTER.NORTH-LONDON.AC.UK
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Alastair Aitken CLMS <ZPALASTAIR@CLUSTER.NORTH-LONDON.AC.UK>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Automated forms
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

Christian "L." Mogensen <mogens@EDU.Stanford.CS> @ Wed, 29 Jun 1994 12:33:42 -0700 (PDT)

>For short lists, you can just as easily use the existing FORM features.
>For long lists - you need to talk to the server again, and therefore
>should delay that to SUBMIT time.

>If you need clever forms, why not use a more suitable tool

I think this is reasonable and so I will stop.  Given that the browsers
appear to wait whilst the form is SUBMIT-ed it seems most practicable to
allow the server side of the transaction to verify data before completing
the transaction.  This would allow the server to return forms that are
incorrectly completed to the browser.

It occurs to me that if the server is getting a submitted form from, say, a
VMS client in use by many processes, then returning the form correctly may
be slightly problematic.  In any event Christian's solution places the onus
on me to produce the code behind CGI and preserves the "simplicity" of
HTML+.  No criticism, but if I tried to teach some of my IP's the table
handling examples I've seen on this list they'd never speak to me again. 

There are 50 ways to leave your lover and more to put together an HTML doc.

Thanks all,

Al. <-:< (zpalastair@grid.unl.ac.uk)