CGI.pm: controlling Back & Reload
David Efflandt
>
>I'm using CGI.pm to write a CGI application that causes new records to
>be entered in a database. The structure of the site is
>
> [ok] [submit]
> Data Entry page --> Review page --> Confirmation page
>
>All pages are generated by the same perl script. I would like to
>arrange things such that, if the user is at the Confirmation page,
>hitting the "Back" button will send him/her to the page visited before
>the Data Entry page. (Currently, hitting the "Back" button while
>visiting the Confirmation page sends the user to the Review page.)
>
>Is there a way to do this?
The first time the script is accessed with no parameters (to generate the
first form), test the referer() and set it to a default (like your home
page) if referer() does not have a value. Then pass this as a hidden
variable through your forms and use that for your own back link on the
last form (assuming CGI.pm function mode).
# Only before printing first form
$_ = referer() || 'http://some_default_url/';
param('referer',$_);
# Withinn all forms including the first
print hidden('referer');
# Any place you want a back link
print a({href=>param('referer')},'Back to " . param('referer'));
--
David Efflandt effl...@xnet.com http://www.de-srv.com/
http://www.autox.chicago.il.us/ http://www.berniesfloral.net/
http://hammer.prohosting.com/~cgi-wiz/ http://cgi-help.virtualave.net/
Alan J. Flavell
> The first time the script is accessed with no parameters (to generate the
> first form), test the referer() and set it to a default (like your home
> page) if referer() does not have a value. Then pass this as a hidden
> variable through your forms and use that for your own back link on the
> last form (assuming CGI.pm function mode).
You give an ominous impression of having failed to read Abigail's
classic web page on the topic. What you're creating is a forward link
(all links are forward links in that sense), that might or might not
take the hon. usenaut forward to the place they came from, leaving
them even more confused than they were before.
And your procedures will have no effect on "the Back button", which
was what the OP was asking about.
And, I'd surmise, still not solving the real problem that the OP is
really concerned about.
I'd recommend the OP to take on board the fact that on the WWW,
browser Back and Reload buttons do what they are designed to do, and
users expect them to do that. Any attempt to change that is both
misguided and ultimately doomed. Work _with_ it, instead of trying to
fight it. The server/script is capable of being under your control:
the user and their browser is not - they will do what they do, so
devise a solution that copes with it. (The details of that aren't a
Perl language question, but the general issue of how to approach a
programming task seems, if I may say so, still to be on-topic for the
group).
This looks to me to be another case of "premature closure": the
questioner wanted to solve some not very clearly stated X, they
concluded that Y and Z were components of a solution, and now they're
asking how to implement Y and Z. Take a step back, look at the bigger
picture, free yourself of this inappropriate partial solution.
Randal L. Schwartz
Alan> This looks to me to be another case of "premature closure": the
Alan> questioner wanted to solve some not very clearly stated X, they
Alan> concluded that Y and Z were components of a solution, and now they're
Alan> asking how to implement Y and Z. Take a step back, look at the bigger
Alan> picture, free yourself of this inappropriate partial solution.
On IRC chatting (EFnet #perl, to be precise), we call this an "XY
problem" for shorthand. Alan of course has made it more complicated
by introducing another variable. :) :)
It's important for me as a person who's been on the listening end of
questions for many years, and who has to listen professionally (and
most of the time answer professionally) to realize that all problems
are pieces of solutions to larger problems. (Think about it a second,
and you'll see that its necessarily so, all the way back to "why the
heck did I get out of bed today?", if not higher.) So, to answer
question Y, without understanding larger problem (the context) X, will
most likely *not* help them entirely with X. I actually consider
that a bit irresponsible.
How it shows up in the chatrooms (or even live, but rarer) is that
someone will say "how do I do Y?". I usually take a deep breath
before answering, and try to understand who a person would have to be
to *ask* about Y, and make sure that I know enough about all possible
X's to verify that an answer is invariant (doesn't depend) on those.
Often, my spider sense will tingle, and I start asking the context
questions, but at the same time, I see a lot of other people answering
the Y question literally. More often than not, they have presumed too
much, and it sends the person off with premature answer that really
doesn't help solve X or Y entirely.
So, the key is to listen, and try to crawl inside the head of the
requestor to see why they would even have that question. It helps to
be appropriate. When I'm doing it live while teaching, it also keeps
me on my toes, as I have to do this in a way that respects the
questioner *and* still keeps the rest of the classroom interested.
Fun, and challenging at the same time. It's one of the parts of
teaching that I most enjoy.
print "NOT just another Perl trainer," # :-)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Bart Lateur
>Alan> This looks to me to be another case of "premature closure": the
>Alan> questioner wanted to solve some not very clearly stated X, they
>Alan> concluded that Y and Z were components of a solution, and now they're
>Alan> asking how to implement Y and Z.
>On IRC chatting (EFnet #perl, to be precise), we call this an "XY
>problem" for shorthand.
>It's important for me as a person who's been on the listening end of
>questions for many years, and who has to listen professionally (and
>most of the time answer professionally) to realize that all problems
>are pieces of solutions to larger problems.
Too bad that the actual, more general problem, X, is usually not
considered an appropriate topic for this newsgroup. Y has more of a
chance to look like a Perl problem.
--
Bart.
nob...@mail.com
> I'm using CGI.pm to write a CGI application that causes new records to
> be entered in a database. The structure of the site is
>
> [ok] [submit]
> Data Entry page --> Review page --> Confirmation page
>
> All pages are generated by the same perl script. I would like to
> arrange things such that, if the user is at the Confirmation page,
> hitting the "Back" button will send him/her to the page visited before
> the Data Entry page. (Currently, hitting the "Back" button while
> visiting the Confirmation page sends the user to the Review page.)
>
> Is there a way to do this?
The back button functionality is usually implemented entirely
client-side. If there is any way to do it it will involve
reporgramming the client with client-side scripts or whatever.
> Or else, is there any way to tell if a page has been reached via the
> Back button?
Not server-side there isn't, because no message passes from the client
to the server when the back button is clicked.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
David Combs
Randal L. Schwartz <mer...@stonehenge.com> wrote:
<SNIP>
>Often, my spider sense will tingle,
Now, THAT is one neat expression. Mind if we all steal it?
David
Randal L. Schwartz
>> Often, my spider sense will tingle,
David> Now, THAT is one neat expression. Mind if we all steal it?
I actually saw it here on CLPM a year or two back, and have been using
it for a while now. And yes, it's a call-back to the days when I
watched Spiderman on saturday mornings. That'd be 1967 to 1970, if
the IMDB is right.
"Spiderman, spiderman, does whatever a spider can; is he good, listen
bud, he's got radioactive blood... hey there, there goes the
spiderman!"