CGI style -- alternatives to HIDDEN parms?

[Keary Suska]

I think your options are pretty much on the mark, but there others. If you
can force your users to use JavaScript, you can have a hidden field with a
name, say, "updated", and have an onChange event that sets the field.
Although I don't recall exactly how a reset would effect this, so you might
have to manually unset the field in that case. If JavaScript is not a
reliable option, you could provide a hidden field with an MD5 hash key of
the original data. Compare the MD5 of what is submitted to the hidden field
to determine if it has changed. In this case a lot less data is being sent
back and forth, and since the MD5 module is C code, it's pretty fast.

Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"

> From: "Tim Chambers" <tbchambers at yahoo.com>
> Date: Thu, 2 Aug 2001 11:04:43 -0600
> To: "Pikes Peak Perl Mongers" <pikes-peak-pm-list at happyfunball.pm.org>
> Subject: CGI style -- alternatives to HIDDEN parms?
> 
> Dear Perl Mongers,
> 
> I am writing a Perl CGI script that updates some information in a database.
> The field can be hundreds of lines of text. If the field hasn't been
> touched, then I don't want to update it in the database. (The database logs
> updates, and we don't want redudant log entries.) The user will press a
> Submit button, at which point I need to decide which fields to update in the
> database. I'm assuming there isn't a simple way of detecting which fields
> were modified from their initial values. Am I wrong? I see my options this
> way:
> 
> 1. Query the database and compare before deciding whether to update. The
> downside is that database queries are relatively expensive in time and
> resources.
> 
> 2. Use a HIDDEN parm to forward the original field contents, then compare it
> with the new value to see if it's changed. But I'm concerned about sending
> contents (remember -- the field could be hundreds of lines of text) back and
> forth between client to server. Should I be? I studied
> http://www.w3.org/TR/html4/interact/forms.html but found nothing talking
> about length limits on such data.
> 
> 3. Cache it on the server somehow. This would just be a cache of the
> database, though.
> 
> I'm leaning toward #2. It seems wasteful, though.
> 
> What do you all think?
> 
> <>< Tim
> 
> 
>