handle multiple submit button.

S

sam

Hi group,

My pervious post may be better described as a perl case.
How can I write a perl script to process multiple request from submit
buttons?

Thanks
Sam
 
G

Gunnar Hjalmarsson

sam said:
My pervious post

Which previous post?
may be better described as a perl case.

It's rather a CGI question. Anyway, it's trivial, and I'll try to answer it.
How can I write a perl script to process multiple request from submit
buttons?

Name the buttons, for instance:

<input type="submit" name="optA" value="Option A">
<input type="submit" name="optB" value="Option B">

In the script:

use CGI;
my $q = new CGI;

if ( $q->param('optA') {
# do something
} else {
# do something else
}
 
S

sam

Gunnar said:
sam wrote:




Name the buttons, for instance:

<input type="submit" name="optA" value="Option A">
<input type="submit" name="optB" value="Option B">

In the script:

use CGI;
my $q = new CGI;

if ( $q->param('optA') {
# do something
} else {
# do something else
}
My current perl script only is written full of print statements, with
the following form:

print "<form action=main.cgi>\n";
....
print "<input type=submit value=\"callself.pl\">\n";
print "</form>";
....

Do I need to change all print statements with CGI?

Thanks
Sam
 
L

Lars Eighner

the lovely said:
Hi group,
My pervious post may be better described as a perl case.
How can I write a perl script to process multiple request from submit
buttons?

First, there is no such thing as "multiple request from submit
buttons." Either you do not know exactly what you want to do,
or you have expressed yourself very poorly.

Second, you offer no evidence that you have tried to solve your
problem yourself. You haven't really told us what you mean by a
"submit button." I have to guess that it has something to do
with a document you want to put on the World-Wide Web - but that
is just a guess. If that guess is correct, you need to look up
CGI on your favorite search engine and work a few of the fine
introductory tutorials that are available. Because what you
want to do is unclear, it may be that CGI will not be helpful.
You may want a client-side solution (which has nothing to do
with perl), or you may want to do something that cannot be done
at all.

Third perl is not CGI. If you research your problem
sufficiently to have a reasonable belief that a server-side
solution is appropriate, then there is a good chance that perl
would be a good choice for your CGI (but there is a
not-insignificant chance that another fine CGI-compliant
language would be more appropriate). If you get that far, you
need to look at the perl CGI module, but you will have to have a
clear understanding of your problem and a basic understanding of
both html and perl.

It comes down to what in the world can you mean by "process
multiple request from submit buttons"? Many CGI scripts (many
of them written in perl) can field several different kinds of
requests and can do several things with any request that is
recognized. The whole idea of CGI is that several instances of
scripts can run at the same time to handle requests from
different clients - and that entails some effort to assure that
the several clients do not step on any data they may both try to
access at the same time. An html document can include several
forms, and each form can have several submit buttons. But the
client (i.e. browser) will send its request more or less
immediately when any one submit button is hit, so it is
impossible to activate several submit buttons simultaneously -
and that has nothing to do with perl.
 
S

Sherm Pendley

sam said:
My pervious post may be better described as a perl case.

What previous post? This is a new thread. If you want to post a
followup, post a followup.

sherm--
 
C

Chris Mattern

Michele said:
Pay attention: he never said "previous post"...
;-)
Hey, stop make pervious posts! There's already too much pervy
stuff on the internet!
--
Christopher Mattern

"Which one you figure tracked us?"
"The ugly one, sir."
"...Could you be more specific?"
 
G

Gunnar Hjalmarsson

sam said:
My current perl script only is written full of print statements, with
the following form:

print "<form action=main.cgi>\n";
...
print "<input type=submit value=\"callself.pl\">\n";
print "</form>";
...

That means that the form is not part of a static HTML page, but included
in a page generated by the script.
Do I need to change all print statements with CGI?

I'm not able to tell; it depends on what it is you want to do.

I would suggest that you pick a tutorial about CGI programming in Perl
and spend some time with it. This link may be helpful:

http://cgi.resourceindex.com/Documentation/CGI_Tutorials/

When you feel you are ready, write a *very short* script that
illustrates the principles of what you want to do. If you encounter
problems, please feel free to ask again. Dependent on the nature of your
problems, this group may be the right place to post, but if it's about
HTML or CGI rather than Perl, you'd better post to
comp.infosystems.www.authoring.cgi instead.

Good luck!
 
T

Tad McClellan

Chris Mattern said:
Hey, stop make pervious posts! There's already too much pervy
stuff on the internet!


Yeah, like a unique per-version number for each version of a software.
 
I

ioneabu

Lars Eighner wrote:
....
Third perl is not CGI.

Just look at the Larry Wall home page to see that this is true. On the
other hand, I have found CGI programming via CGI.pm is the best user
interface to Perl programs. It is very simple, even easier than
actually fully understanding HTML and CGI programming without CGI.pm,
and it is as portable as you can get. No virtual machine to install,
just an up-to-date browser on just about any current OS (assuming you
have access to one of the many low cost web hosters). A google search
for 'CGI.pm home page' brings up the official home page with everything
you need to know about CGI.pm. I bought the books anyway because I
felt that Dr. Lincoln Stein is a great man and deserves all the book
sales he can get. I wonder why he doesn't publish with O'Reilly. I
don't know much about the inner-circle of Perl, but his CGI.pm work is
discussed in every O'Reilly Perl book that I have read, so why is he
with a different publisher?

Anyway, if you want to really have fun programming, immerse yourself in
CGI programming with Perl. I can't get enough of it.


wana
 
I

ioneabu

Sherm said:
I'm actually quite fond of CamelBones.pm for UIs myself. But I suppose
I'm a bit biased. :)


Eh?

Thanks for the link! I had no idea. The two books I have by him are
from different publishers. The official CGI.pm guide and the one on
network programming with Perl. I will have to check out those others.
Also will have to take a look at CamelBones.pm. Thanks!

wana
 
L

Lars Eighner

In our last episode,
the lovely and talented (e-mail address removed)
broadcast on comp.lang.perl.misc:

Lars Eighner wrote:
...
Just look at the Larry Wall home page to see that this is true. On the
other hand, I have found CGI programming via CGI.pm is the best user
interface to Perl programs.

As it happens, I was working on the README for my small
databases manager (to use a number of databases similar to and
including various old DOS-type databases, spreadsheets, and
various "office suite" type applications -- no, it is not nearly
done, but I tend to document as I go because I am too senile to
remember what I did yesterday if I haven't documented) and I was
trying to explain (in the README) why a cgi interface for a
program that is *not* intended for a public server on the
world-wide web.

You see, there just is no trick to programming. It is easy.
And anyone with a computer should give it a try. The trick -
what the professionals get paid for - is making programs run on
many different computers, with many different OSs, i/o devices,
etc. That stuff is really, really hard - and there are dozens,
even hundreds, of vendors out there trying all the time to
produce new hardware to break your application.

But html forms have a fairly complete toolkit for data input,
html has an adequate way of marking up output, and most browsers
do a pretty good job of presenting html documents - particularly
if you give them a chance to do their jobs instead of trying to
throttle them into absolute presentational subservience (and if
you trust users to configure their browsers in a way that is
most comfortable for them).

CGI takes care of the nasty stuff so even an idiot can write
programs that do useful things. There ought to be a word for
not-necessarily-for-the-web cgi programming.

Here's a hint, even if you have a local server, lynx - compiled
and configured for lynxcgi if it is available for your platform
- is a really helpful tool for working on these kinds of
applications.

I'd be happy to know of other browsers that have some scheme for
running cgi without a server (not that it is brain surgery - the
browser just has to provide a - usually - minimal environment,
launch the script, and catch and render the output). I run a
server locally, and at some point I move applications to it for
testing. But at the still-sort-of-vague-on-things level,
browser cgi is great. And for personal-type applications,
browser cgi might be the best solution.
 
M

Matt Garrish

Michele Dondi said:
Pay attention: he never said "previous post"...
;-)

And unlike some newbies, he admits he's open to new ideas. I prefer pervious
posters to impervious ones...

Matt
 
M

Matt Garrish

Abigail said:
(e-mail address removed) ([email protected]) wrote on MMMMCXXXVII September
MCMXCIII in
<URL:''
'' Lars Eighner wrote:
'' ...
'' > Third perl is not CGI.
''
'' Just look at the Larry Wall home page to see that this is true. On
the
'' other hand, I have found CGI programming via CGI.pm is the best user
'' interface to Perl programs. It is very simple, even easier than
'' actually fully understanding HTML and CGI programming without CGI.pm,
'' and it is as portable as you can get. No virtual machine to install,
'' just an up-to-date browser on just about any current OS (assuming you
'' have access to one of the many low cost web hosters). A google search
'' for 'CGI.pm home page' brings up the official home page with
everything
'' you need to know about CGI.pm. I bought the books anyway because I
'' felt that Dr. Lincoln Stein is a great man and deserves all the book
'' sales he can get. I wonder why he doesn't publish with O'Reilly. I
'' don't know much about the inner-circle of Perl, but his CGI.pm work is
'' discussed in every O'Reilly Perl book that I have read, so why is he
'' with a different publisher?

+ Perhaps because not everyone is convinced O'Reilly is the best publisher
under the sun?

And judging a book by its publisher is such a bad idea. I'd rather get a
Conway book on Perl published by Manning or a Stein book by Addison-Wesley
than an O'Reilly book by some unknown...

Matt
 
J

Joe Smith

sam said:
My current perl script only is written full of print statements

That's not recommended practice. Do you know about 'here' documents?

print <<"END_OF_MESSAGE";
<form action=main.cgi>
...
Do I need to change all print statements with CGI?

To fully utilize the methods defined in CGI.pm, yes.
-Joe
 

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

Forum statistics

Threads
473,774
Messages
2,569,599
Members
45,165
Latest member
JavierBrak
Top