Error trapping in Perl-generated page

E

Ed Jay

I generate a page using a Perl script ("Page 1"). The page has a
multi-question form that is submitted to a second Perl script that creates
the next page ("Page 2").

Page 1 has a couple of questions that assigns values (0 or 1) to variable
$A and to variable $B. $A and B$ cannot each have the value 1. I'm trying
to trap the potential input error that results in $A = $B = 1.

Clearly I can submit the form values to Page 2 and have Page 2 test for
the error, print an error message and have the operator press a button to
return to Page 1. IOW, read all variables sent from Page 1, test for the
error, and if the error exists use a form to resubmit the form to
Page 1, otherwise continue to process Page 2, as follows:

E.g.,

Submit Page 1 variables to Page 2
Page 2 reads in variables from Page 1
if ($A && $B != 1) {process Page 2} #then goto Page 3
else {
print the error message
<FORM ACTION=cgi-bin/page_1.cgi\" METHOD=\"POST\">
<input type=submit value="Press here to go back to Page 1">
}

I'd prefer to have the form automatically proceed back to Page 1 if
there's an error instead of having the op press another button..

Two questions:

1. How can I either test the error while still on Page 1?

2. How do I test for the Page 1 error on Page 2 and automatically return
the op to Page 1 for corrections?

Thanks.
 
M

mbstevens

Ed said:
Two questions:

1. How can I either test the error while still on Page 1?
JavaScript, but you still need to test server side because this won't
work for every visitor. If it gets to page 1 with bad values,
regenerate the page with all but the bad values filled in, and a message
added indicating values to be corrected.
2. How do I test for the Page 1 error on Page 2 and automatically return
the op to Page 1 for corrections?
CGI.pm saves state. You'll probably be able to figure out what you need
from looking at the following pages:

http://www.foo.be/docs/tpj/issues/vol1_2/tpj0102-0004.html

http://www.perl.com/doc/manual/html/lib/CGI.html#SAVING_THE_STATE_OF_THE_SCRIPT_T

....and Google for "CGI.pm save state" for more.
 
G

Guillaume

Ed Jay:
1. How can I either test the error while still on Page 1?
Javascript

2. How do I test for the Page 1 error on Page 2 and automatically return
the op to Page 1 for corrections?

Redirect (set the appropriate headers + eventualy javascript code)
 
E

Ed Jay

JavaScript, but you still need to test server side because this won't
work for every visitor.

My audience is limited to subscribers to a service and one of the
conditions is that they must have javascript enabled. That said, am I to
presume a javascript to poll the answers to my two problematic questions
is what you're suggesting?
If it gets to page 1 with bad values,
regenerate the page with all but the bad values filled in, and a message
added indicating values to be corrected.

Not difficult to do, except that the questions are answered with
checkboxes or radio boxes and without doing a ton of conditional tests for
each question, I don't know how else to show the state of each answer box.
CGI.pm saves state. You'll probably be able to figure out what you need
from looking at the following pages:

http://www.foo.be/docs/tpj/issues/vol1_2/tpj0102-0004.html

http://www.perl.com/doc/manual/html/lib/CGI.html#SAVING_THE_STATE_OF_THE_SCRIPT_T

...and Google for "CGI.pm save state" for more.

Saving the state is trivial, except for the checkmarks in each answer
button.

In fact, the methods shown in the Perl docs seem to be a bit heavy. I read
in the variables, do the error checking, and if there's an error, I
resubmit to the original page with all the variables in hidden form
fields. It works fine, save those damned checkmarks.

As I type this, I just had a thought. Go to Page 2 (or a dedicated error
checking page) and check for the error. If the error exists, print the
error message and either use either <a href="javascript:history.back()">
or a message telling the op to use his browser's 'Back Button' to return
to Page 1. The complete state is save in the cache.
 
E

Ed Jay

Guillaume said:
Ed Jay:

Redirect (set the appropriate headers + eventualy javascript code)

Understood; however, I either have to regenerate Page 1 with a new error
message, or stop at Page 2 with the error message and then resubmit to
Page 1 with all the 'good' variables intact and figure out how to
check/uncheck checkbox buttons on Page 1.

I may have figured an easy solution explained in my very recent post in
response to mbstevens, i.e., print the error message on Page 2 and use
javascript to return the guy to Page 1 as held in the cache. The only
issue I see with this method is unchecking the checkboxes or radio buttons
that were incorrectly checked.
 
M

mbstevens

Ed said:
My audience is limited to subscribers to a service and one of the
conditions is that they must have javascript enabled.

Hmm. So, when people who hate javascript visit, they have to re-set
their browser, and then re-re-set it on leaving. Are you sure that you
really _need_ to require your visitors to use javascript? I once did
banking at a place that required that, and it irritated the hell out of me.
That said, am I to
presume a javascript to poll the answers to my two problematic questions
is what you're suggesting?

Well, I don't know fully what the questions are, but yes, other things
being equal, a JS check will usually work.
Not difficult to do, except that the questions are answered with
checkboxes or radio boxes and without doing a ton of conditional tests for
each question, I don't know how else to show the state of each answer box.

Well, you could just generate a page to re-ask the problem question with
the same script, if you wanted.

As I type this, I just had a thought. Go to Page 2 (or a dedicated error
checking page) and check for the error. If the error exists, print the
error message and either use either <a href="javascript:history.back()">

<a href="javascript:history.go(-1);">Back</a>
Doesn't always work, even with JS enabled. You'll also have to require
your subscribers to use their browser's history list, which some people
disable, for instance with security software.

or a message telling the op to use his browser's 'Back Button' to return
to Page 1. The complete state is save in the cache.
As long as you can already program some in Perl, just do it right and
generate a page with a script to get the information needed. All this
jumping around in javascript sounds a bit kludgy for my taste, but it's
your page.
 
E

Ed Jay

mbstevens said:
Hmm. So, when people who hate javascript visit, they have to re-set
their browser, and then re-re-set it on leaving. Are you sure that you
really _need_ to require your visitors to use javascript? I once did
banking at a place that required that, and it irritated the hell out of me.

lol. My subscribers are medical doctors and the computer they'll (actually
their techs) will be using are probably already enabled for js.
Well, I don't know fully what the questions are, but yes, other things
being equal, a JS check will usually work.


Well, you could just generate a page to re-ask the problem question with
the same script, if you wanted.
Problem is that there are many questions, so there would be a lot of data
re-entry to do.
<a href="javascript:history.go(-1);">Back</a>
Doesn't always work, even with JS enabled. You'll also have to require
your subscribers to use their browser's history list, which some people
disable, for instance with security software.
Good point. Thanks.

As long as you can already program some in Perl, just do it right and
generate a page with a script to get the information needed. All this
jumping around in javascript sounds a bit kludgy for my taste, but it's
your page.
I'm trying to be as non-kludgy as possible, but without having to resort
to lengthy scripts.
 
M

mbstevens

Ed said:
lol. My subscribers are medical doctors and the computer they'll (actually
their techs) will be using are probably already enabled for js.

I wasn't talking about 'enabled', I was talking about visitors that just
don't like to use it. This could be for security reasons, or just
because they don't like it.
I'm trying to be as non-kludgy as possible, but without having to resort
to lengthy scripts.
I don't think it would have to become lengthy. You would just need to
use conditionals to determine which parts of the page to re-generate
given the answers received. One easy way would be to use templates:
http://www.mbstevens.com/cgi/mkatt.pl?name=cgi_perl/html_through_cgi
may help.
Or, you could just keep markup snippets in variables.

A certain level of complexity is going to be needed to do what you want.
Doing things in JavaScript won't alleviate that -- it will only
spread the burden to a second programming language, making the site just
that much harder to keep up.
 
J

Jonathan N. Little

Ed said:
Understood; however, I either have to regenerate Page 1 with a new error
message, or stop at Page 2 with the error message and then resubmit to
Page 1 with all the 'good' variables intact and figure out how to
check/uncheck checkbox buttons on Page 1.

I may have figured an easy solution explained in my very recent post in
response to mbstevens, i.e., print the error message on Page 2 and use
javascript to return the guy to Page 1 as held in the cache. The only
issue I see with this method is unchecking the checkboxes or radio buttons
that were incorrectly checked.


Normally I would approach a multi-page form with a single Perl script,
which posts back to itself on each step. Process the query in a matrix
before generation of the page so if the 1st page's fields pass muster it
will then generate the 2nd page's form with 1st page's fields in hidden
fields, if not then regenerate 1st page with bad fields marked. And then
so on for each page. Than I add a JavaScript validation for each page so
IF the visitor has JavaScript enabled, the script can interrupt the
submission and alert the error fields without a server call. A nice
option but not required because it will be validated again by the CGI.
 
E

Ed Jay

mbstevens said:
I wasn't talking about 'enabled', I was talking about visitors that just
don't like to use it. This could be for security reasons, or just
because they don't like it.
Understood
I don't think it would have to become lengthy. You would just need to
use conditionals to determine which parts of the page to re-generate
given the answers received. One easy way would be to use templates:
http://www.mbstevens.com/cgi/mkatt.pl?name=cgi_perl/html_through_cgi
may help.
Or, you could just keep markup snippets in variables.

A certain level of complexity is going to be needed to do what you want.
Doing things in JavaScript won't alleviate that -- it will only
spread the burden to a second programming language, making the site just
that much harder to keep up.
Agreed.

I almost feel stupid. I solved my problem in the most elementary
manner...without js or any error checking.

There are three questions. The first asks if either $A or $B should be
set. The second asks if $A should be set, and the third asks if $B should
be set. Subsequent processing queried the values for $A and $B. This is
why $A and $B could concurrently be set.

I renamed all variables to $C, but give different values, e.g., if nether
$A or $B are set then $C == 0. If $A is set then $C == 1. If $B is set $C
== 2. Using radio buttons all named $C, it's not possible to concurrently
set $A and $B.

During data processing, I simply test the value of $C.

I wonder how I'll waste tomorrow. :-(
 
E

Ed Jay

Jonathan N. Little said:
Normally I would approach a multi-page form with a single Perl script,
which posts back to itself on each step. Process the query in a matrix
before generation of the page so if the 1st page's fields pass muster it
will then generate the 2nd page's form with 1st page's fields in hidden
fields, if not then regenerate 1st page with bad fields marked. And then
so on for each page. Than I add a JavaScript validation for each page so
IF the visitor has JavaScript enabled, the script can interrupt the
submission and alert the error fields without a server call. A nice
option but not required because it will be validated again by the CGI.

I started with a single Perl script, but when it reached the 100kB level,
I decided that in the interest of saving time, I'd better break it into
smaller modules. (The sum of 6 modules is now up to 250kB. It's going to
get bigger yet.)

Anyway, I solved my issue as explained to mbstevens.
 
R

Robert Latest

On Mon, 07 Nov 2005 16:04:15 -0800,
in Msg. said:
There are three questions. The first asks if either $A or $B should be
set. The second asks if $A should be set, and the third asks if $B should
be set.

That's way over the top for most MDs anyway. You must redesign your
site.

robert
 
E

Ed Jay

Robert Latest said:
On Mon, 07 Nov 2005 16:04:15 -0800,


That's way over the top for most MDs anyway. You must redesign your
site.
That's why I said the tech does the data entry. :)

Seriously,.I was speaking symbolically, Robert. :) Example:

($A or $B)
"If no other clinical signs, do either sides of the lumbar show symptoms?
Left? Right?"

($A)
"The left side shows significant pathology. Is the Left side
of the lumbar symptomatic? Yes? No?"

($B)
"The right side shows significant pathology. Is the Right side
of the lumbar symptomatic? Yes? No?"

Thanks for the advice.
 
C

Chris Beall

Ed said:
I generate a page using a Perl script ("Page 1"). The page has a
multi-question form that is submitted to a second Perl script that creates
the next page ("Page 2").

Page 1 has a couple of questions that assigns values (0 or 1) to variable
$A and to variable $B. $A and B$ cannot each have the value 1. I'm trying
to trap the potential input error that results in $A = $B = 1.

Clearly I can submit the form values to Page 2 and have Page 2 test for
the error, print an error message and have the operator press a button to
return to Page 1. IOW, read all variables sent from Page 1, test for the
error, and if the error exists use a form to resubmit the form to
Page 1, otherwise continue to process Page 2, as follows:

E.g.,

Submit Page 1 variables to Page 2
Page 2 reads in variables from Page 1
if ($A && $B != 1) {process Page 2} #then goto Page 3
else {
print the error message
<FORM ACTION=cgi-bin/page_1.cgi\" METHOD=\"POST\">
<input type=submit value="Press here to go back to Page 1">
}

I'd prefer to have the form automatically proceed back to Page 1 if
there's an error instead of having the op press another button..

Two questions:

1. How can I either test the error while still on Page 1?

2. How do I test for the Page 1 error on Page 2 and automatically return
the op to Page 1 for corrections?

Thanks.
Ed,

Reverse your logic:
If no input is present, Perl1 generates a blank-form HTML Page 1. On
Submit, return control to the SAME Perl1 code. That code validates the
input and, if valid, calls Perl2 to generate HTML Page 2, passing
parameters as needed. If the input is NOT valid, Perl1 regurgitates
HTML Page1, with all prior input unchanged, and with appropriate error
indications (red color, out-of-range message, etc.)

Each Perl module is therefore responsible for:
- Testing whether input is present (first-time not) ex: if (exists
$form{"parm1"})
- Generating an initial HTML page
- Fielding the user's response from that page
- Validating the user's input
- Passing control to the next module only if the input is valid

Chris Beall
 
E

Ed Jay

Chris Beall said:
Ed,

Reverse your logic:
If no input is present, Perl1 generates a blank-form HTML Page 1. On
Submit, return control to the SAME Perl1 code. That code validates the
input and, if valid, calls Perl2 to generate HTML Page 2, passing
parameters as needed. If the input is NOT valid, Perl1 regurgitates
HTML Page1, with all prior input unchanged, and with appropriate error
indications (red color, out-of-range message, etc.)

Each Perl module is therefore responsible for:
- Testing whether input is present (first-time not) ex: if (exists
$form{"parm1"})
- Generating an initial HTML page
- Fielding the user's response from that page
- Validating the user's input
- Passing control to the next module only if the input is valid
Excellent, Chris. Thanks for the direction.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top