<[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> 1)
> Basically I have n + (5 or 6) texstfields to fill, initially from a file
which works fine. Then the user makes changes and submits changes to the
same script (don't want to use 2 scripts ideally), which identifies that it
has been called via form (POST etc., "if(param())" ).
never write 2 programs to do one job.
>
> Then it's job is to eliminate empty fields, and display n + (5 or 6)
fields with the user data submitted. (see PROBLEM SECTION)
>
> The PROBLEM is that the text/input fields are given the default values
from what the user entered before submitting, and for some reason my
processing doesn't overwrite these defaults.
CGI.pm has what it calls "sticky" behavior turned on by default. This is
probably the only thing I dont like about CGI.pm. Read about it in the docs.
There are a few ways around it, but what I do is run this code somewhere
near the top of my script:
my(%input);
for my $field_name ( $q->param() ) {
$input{ $field_name } = $q->param( $field_name );
}
$q->Delete_all;
So I just use the %input hash to get at my input values. But now $q->param()
wont return anything (with or without arguments) because you just deleted
the data from the $q object.
then I have skeleton code that looks like this: (I know you have a handle on
this part, Im just putting it here for... fun I guess. I did comment on the
use of CGI.pm to dynamically build tables below this)
# $input{state} comes from a submit button that has it's
# name property set to "state" and it's value property
# set to "Review Selections". It gets put into the
# %input hash because of the code above
if ($input{state} eq 'Review Selections') {
my(@bad_fields) = find_invalid_input( %input );
if ( scalar(@bad_fields) ) {
# dump a html form that redisplays the
# bad fields and make hidden fields for
# the good ones. Give the submit button
# the same name/value pair so during the
# next submission, the input is rechecked
# fo invalid input
} else { # okay to print confirmation menu
# print a html document that shows
# all the user selections. Inside the document,
# print a form that puts all names/values in hidden fields,
# and make the submit button have a name property
# of "state" and a value of "Confirm Selections".
# this is how you maintain state =0).
}
} elsif ($input{state} eq 'Confirm Selections') {
# stick the data in a database
# email it to yourself
# fax it to yourself
# and dont forget to to print a html form
# telling the user to take a hike (not in those words)
} else {
die('Usage Error');
}
> 2)
> Any info on getting control over Tables while using CGI.pm also greatfully
received. As you can see I would like to be consistent, but due to time
constarints have had to sacrafice my honor for progress.
> Gave up looking for answers after reading several posts on this subject on
this list and others. My current conclusion is that putting loops and such
like inside Tables can't be achieved using CGI.pm as-it-is. (Which seems
strange to me as tables are quite often the result of a loop.)
CGI.pm makes it very easy to build dynamic tables. Its probably my favorite
feature. No matter what you want, it can most assuredly be built by using
loops, but the cool thing about CGI.pm is you dont have to use loops to
build tables. You will need to get a handle on perl references, because the
$q->tr(), and $q->td() methods in CGI.pm take references to build those
dynamic tables.
read: perldoc perlref
and then (re)read: perldoc -m CGI
and then (re)reread: perldoc -m CGI
or check the docs at perldoc.com
trw3
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
