in reply to generarting dynamic html using perl

I like using one script, but the drawback is that your script quickly grows into 100's of lines of 'static' HTML. If the forms you are displaying to the user are large and you want to keep your script from being cluttered, consider storing the HTML for these in seperate text files, then pulling them into the script where appropriate.

Keeping values across several pages:

Try to avoid the cookie route. I get more problems than solutions with cookies, especially with sites that have a lot of AOLer's and/or WebTV users as customers.

Here are the questions I ask myself when I have a form that spans several pages.

- Is it important that the user not be able do see the information they entered previously?
If you don't care if the user sees previous answers, you can stick these variables into hidden fields on the next form page. This means that you don't do any writes to your database/table until the user has completed the whole process.

# Generate hidden fields from previous form # List all field names here @keepers = qw( first_name last_name address ); # Flip through %fields hash where you have inputs # stored, and stick them into a hidden fields foreach (@keepers){ $hidden.="<input type=\"hidden\" name=\"$_\" value=\"$fields{$_} +\"> \n"; } # Stick the $hidden variable anywhere inside the <FORM> # tags of the next page
- Are you worried about users 'bailing out' of the form process, and want to keep the info they DID enter?
You will need to go with some kind of external database/table that will record the results from each form completion. Then you can pass the record id back to the user as a hidden field.
# For this kind of operation, I like # to use a fast tie hash, especially # if there is a lot of traffic use DB_File; $records = tie %stuff, 'DB_File', "entries.dat", O_CREAT|O_RDWR,066 +6;
Be sure to clean this table up occasionally because users who 'bail' will slowly fill this up with garbage. That's purely a traffic decision though. You might get away with cleaning it once a month, or be required to clean it daily with a cron job.

I hope this has helped more than muddied the question.

Richard
Oakbox

Replies are listed 'Best First'.
Re: Re: generating dynamic html using perl
by mr.dunstan (Monk) on Jun 15, 2001 at 02:53 UTC
    Definitely the big question is, are you allowing partially-filled-out forms to be submitted?

    I usually am against that sort of thing. It's kind of messy, but I would have each successive form get filled up with hidden form fields containing names and values from the previous form, and wait until the final step before submitting anything.

    Also I love using static html pages, it keeps the html out of your perl and that is a good thing!

    Humble initiate,
    mr.dunstan