Re: Clearing a Form

[drieux]

On Monday, Jul 21, 2003, at 15:05 US/Pacific, Peter Fleck wrote:

I have a cgi that creates a form and then receives the output of the 
form and sends it to a mysql database. It also displays the form 
information as a preview of what is getting sent to the database.

You can return to the original form with data if you need to correct 
something via an 'Edit' button. This button also makes sure that 
nothing gets stored in the database (by deleting the data that was 
just sent and I know there must be a better way to do that part but 
it's not my current question).
[..]
I'm wondering if javascript is the answer?
[..]

Let me try to underscore wiggins basic idea.

Javascript can help a part of this, in that
it can do basic checking on the browser side.
If fields foo|bar|baz have to be filled in,
then a quick Java Script
        alert("Must have value in field foo");
        return false;
is a quick way to prevent some of those problems.
The bad news is that with some of the 'pop-up blocker'
software - those alerts will be dumped and the user
will not see them.
SO you need to always write your CGI code as IF
the javascript TOTALLY FAILED. Hence that you
check that the values returned from the form
are kosher and sane.
What I do, is then present a 'verification page'
where they have the option to 'commit' or 'go edit'.
On the 'commit' we actually execute on the DB transaction.

This is where you also need to work out your basic DB transaction model.

I have mine happily say 'yes' to any 'add' for something
that is already there - since, well, yes, it is already there.
I also generically say 'ok' to any 'delete' of things that
do not exist, since, well, they are no longer there.
This way, if the person does use the 'back button' on you,
the worst case is that they will niggle the front end of
your DB transaction system - by trying to delete a deleted record,
or add an already existing record.
What you can then deal with is a 'confirmation' process
if they send you what would be a 'modify' - in which
the record exists, but there are differences between
what is in the current record and the new information.
This too can be caught at the 'validation' stage, with
a 'warning' message - that says something like 'foo already
exists on bar - go to bar?'
So rather than doing an 'update' and recycle, make sure
that they REALLY want to go there before you even talk
to the database....
Other strategies are to do the no-cache pragma, and hope
that the browser honors that. Other tricks are to run
SID's - and to have a table of active SID's - session id's,
and to delete a sid from the table if
        a. the commit occurs
        b. the transaction is older than time allowed
This way if you get a SID for a transaction on a back button
event, that is for something that has already been committed,
then you warn about that.... if the SID is 'aged out' then
you warn about that... Or you take the alternative strategy
that since you can not find the SID in the active sid table,
then you whine that the SID is not there.
You get the sid into the form as a 'hidden' - and you can
then think about dealing with a journaling database model
that will allow you full rollback, etc, etc, etc...
But basically what I would argue is that you get a better back
end model for dealing with the real back end issues.


ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]