I would prefer to preview the data before storing in the DB and had hoped to get this in place but ran into a problem on the way which led to my workaround which and the STORE-PREVIEW-DELETE ENTRY-EDIT sequence. I don't like it either.
The problem is that I am storing a series of entries to a table in a hash with values that reference arrays. I don't think I can store something like that in a hidden form field so I have to rethink/redesign that whole data storage process. Would it be safe to say that only scalar values can really be hidden away in fields on a form? (I also have some values in an array that would have to be taken care of.)
I'm starting to conceive as to how it can be done but I'm also way behind schedule on this project. So the 'good' design will have to be implemented in the next rev of my ap.
Just to provide a bit more entertainment for you experienced perlers, my intermim/ugly hack solution to the back button problem is to add a field in the DB that must be true for the data to display on a Web page. The default value is 'false'. After previewing the data, the user clicks an button which simply sets the display column value to true. So if user uses back button, an extra record will exist in the database but that record will not show up in public display.
Background: This is a data entry system for one person/editor that will then result in dynamic display of information for the public on our Web site. Right now the person is maintaining the page in HTML Netscape Composer so it's hard for anything scripted not to be an improvement. You can check the current site at:
http://www.cancer.umn.edu/page/aboutus/grantopp.html
At 5:27 PM -0500 7/21/03, [EMAIL PROTECTED] wrote:
------------------------------------------------ On Mon, 21 Jul 2003 17:05:57 -0500, Peter Fleck <[EMAIL PROTECTED]> 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).
If the visitor uses the browser 'Back' button to return to the form, their data will be there but the record won't get deleted from the database.
How do I erase all the data from the form if the visitor chooses to use the Back button? I tried the CGI.pm method mentioned in O'Reilly's CGI Programming:
print $dataIn->header( -type => "text/html", -expires => "now");
but that doesn't do it.
I'm wondering if javascript is the answer?
I think the difficulty you are experiencing in your implementation is a direct result and indicator of a design that needs to be re-examined. You are running into the standard problem with a protocol that is stateless (aka HTTP). Rather than switching to use Javascript to handle the "abnormal" use of the browser's back button, you would be better off assuming that 50% of the time that is how a person is going to navigate and do something like store the values as hidden fields in a form on the preview page, then when they use the back button make some edits and resubmit, your script need only re-display the preview page, which makes the implementation easier. Then the data is *only* stored to the DB once the final version is submitted from the preview page. To implement your "edit" feature you need only return them to the original form and pre-fill the fields based on the values submitted in your preview form (which is also your "Edit" form).
Sorry if this is confusing, I would re-examine why and when you store data to the DB in your design rather than the implementation details.
-- Peter Fleck Webmaster | University of Minnesota Cancer Center Dinnaken Office Bldg. 925 Delaware St. SE Minneapolis, MN 55414 612-625-8668 | [EMAIL PROTECTED] | www.cancer.umn.edu Campus Mail: MMC 806
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
