> Another problem is that this will prevent the user from backing up to
> the form after it was submitted, changing the values slightly, and
> submitting again for a slightly different entry, which should still
> be unique.  There may be cases where this is acceptable, and yours

This would also fail under my suggestion.  As Greg points out, in some
cases this isn't a problem, and in others it is.

> Another way to handle this is to have a two-part submission.  The
> first form creates a recrod in the database, but somehow marks it as
> unconfirmed.  You then return a confirmation form with the key for

I listed my objections to this earlier: it clutters up the database with
unfinished "unconfirmed" entries.  This may or may not be acceptable.  In
the case where the potential problem in the first case _is_ a problem,
this is almost certainly the way to go.  Likewise, if you have a problem
with abandoned unconfirmed entries, go with the first solution.  (OTOH,
Marketing people _like_ the unconfirmed entries, because it gives them
data about people who show some level of interest but are unwilling to
commit.

> entry.  This will require some additional maintenance as unconfirmed
> entries will have to be cleared out after some timeout period.

As he said, you can, of course, clean house.



---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/cgiapp@lists.vm.com/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to