Multiple submit actions.

[sam]

Hi,

I tried to create a form which embedded with another form, thus I expect
the second submit button will call the second cgi script, the main
submit button will call the main cgi script seperately.

eg.
print "<Form action=main.cgi>\n";
print "<table>\n";
print "<td><form action=second.cgi>\";
print "<input type=submit value=\"Outlets\">\n";
print "</form></td>\n";
print "</table>\n";
print "<td><form action=queryl.pl><input type=submit
value=\"MainQuery\"></form>\n";

in the above coding, pressed the MainQuery submit button actually called
to main.cgi script instead of query1.pl.

How can I change this?

Thanks
Sam

 

[Jürgen Exner]

sam wrote:
[...]

eg.
print "<Form action=main.cgi>\n";
print "<table>\n";
print "<td><form action=second.cgi>\";
print "<input type=submit value=\"Outlets\">\n";
print "</form></td>\n";
print "</table>\n";
print "<td><form action=queryl.pl><input type=submit
value=\"MainQuery\"></form>\n";

in the above coding, pressed the MainQuery submit button actually
called to main.cgi script instead of query1.pl.

How can I change this?

Your use of the print() function seems to be correct, although some people
would probably recommend to use CGI.pm instead.

If you have questions about HTML or CGI then you may want to ask in a
newsgroup that actually deals with such languague/interface.

jue

 

[sam]

sam wrote:
[...]

eg.
print "<Form action=main.cgi>\n";
print "<table>\n";
print "<td><form action=second.cgi>\";
print "<input type=submit value=\"Outlets\">\n";
print "</form></td>\n";
print "</table>\n";
print "<td><form action=queryl.pl><input type=submit
value=\"MainQuery\"></form>\n";

in the above coding, pressed the MainQuery submit button actually
called to main.cgi script instead of query1.pl.

How can I change this?

Your use of the print() function seems to be correct, although some people
would probably recommend to use CGI.pm instead.

If you have questions about HTML or CGI then you may want to ask in a
newsgroup that actually deals with such languague/interface.

I m sorry I posted this html question in the perl newsgroup.
But I couldn't found a related newsgroup for this. I may be better look
for those forum and mailing list instead.

Thanks
Sam

 

[Chris Mattern]

I m sorry I posted this html question in the perl newsgroup.
But I couldn't found a related newsgroup for this. I may be better look
for those forum and mailing list instead.

I believe the newsgroup you would be looking for is
comp.infosystems.www.authoring.cgi.

--
Christopher Mattern

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

 

[Lars Eighner]

Hi,

I tried to create a form which embedded with another form, thus I expect
the second submit button will call the second cgi script, the main
submit button will call the main cgi script seperately.

This is a basic html question. You have improperly nested
<form> and <table>. This: <form><table></form></table> is
invalid. Furthermore you have <td> in the below AFTER YOU HAVE
CLOSED YOUR TABLE. If you attempted to validate your html, you
would have learned that. Find a basic html tutorial. This has
nothing to do with perl. It has nothing to do with CGI. You
cannot expect to do anything useful with any kind of CGI until
you can write valid html.

You can have two different forms on a page, each of which point
to a different cgi. But you cannot activate both of them at
once. In my humble opinion, it would be much better to have
one cgi as the master and let it invoke the appropriate
subroutine according to the value of the submit button. You can
have as many submit buttons as you please in a form. This is,
however, pointless until you learn html.

Here's a hint: create an html document first and validate it
before you try to get a CGI to produce that document.

eg.
print "<Form action=main.cgi>\n";
print "<table>\n";
print "<td><form action=second.cgi>\";
print "<input type=submit value=\"Outlets\">\n";
print "</form></td>\n";
print "</table>\n";
print "<td><form action=queryl.pl><input type=submit
value=\"MainQuery\"></form>\n";

in the above coding, pressed the MainQuery submit button actually called
to main.cgi script instead of query1.pl.

It is a wonder it did anything at all, being as it is totally
invalid html. Your browser did that in the face of invalid
html. Another browser might have done it differently. There is
no one correct way for browsers to handle invalid html. (It is
true enough that not all browsers do the right thing with every
kind of valid html document, but if you don't give a browser
valid html, it doesn't have a chance.)

How can I change this?

Writing valid html would be a start.

 

[Sherm Pendley]

I tried to create a form which embedded with another form

That's not valid HTML, so what browsers will do with it is undefined.

thus I expect the second submit button will call the second cgi script

You expect too much. What happens in response to valid HTML is well
defined; what happens in response to invalid HTML is not.

print "<Form action=main.cgi>\n";
print "<table>\n";
print "<td><form action=second.cgi>\";
print "<input type=submit value=\"Outlets\">\n";
print "</form></td>\n";
print "</table>\n";
print "<td><form action=queryl.pl><input type=submit
value=\"MainQuery\"></form>\n";

Nothing wrong here, your Perl print() statements are fine. What was your
Perl question?

How can I change this?

Fix your HTML. Ask about that in a more appropriate group - you'll find
them under the "comp.infosystems.www.authoring.*" hierarchy.

sherm--

 

[sam]

Sorry for asking an out of topic question.
I have abandoned the use of CGI in solving this problem.

Thanks
Sam.

 

[Tad McClellan]

I have abandoned the use of CGI in solving this problem.

Why?

Seems to me to be a perfectly good way of solving this problem.

What alternative "solution" have you discovered?

 

[sam]

Why?

Seems to me to be a perfectly good way of solving this problem.

What alternative "solution" have you discovered?

I know it is, but my client does not require this solution. I would
rather focus my effort in other area.

Thanks
Sam

 

[Lars Eighner]

Sorry for asking an out of topic question.
I have abandoned the use of CGI in solving this problem.

But your problem wasn't CGI. It was that you do not write valid
html. You will have problems with anything you put on the web
until and unless you know how to compose valid html.

 

[krakle]

Your use of the print() function seems to be correct, although some people
would probably recommend to use CGI.pm instead.
jue

I would NEVER recommend to use CGI.pm for HTML. Unless you want limited
control and a plain ugly page that can't be easily changed.

 

[Lars Eighner]

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

I would NEVER recommend to use CGI.pm for HTML. Unless you want limited
control and a plain ugly page that can't be easily changed.

HTML gives you limited control. CGI provides for all the hooks
necessary for CSS, and CSS can easily be changed.

 

[Matt Garrish]

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




HTML gives you limited control. CGI provides for all the hooks
necessary for CSS, and CSS can easily be changed.

Hooks necessary for css? If you're talking about style attributes, how would
working on top of an additional layer of abstraction provide better control
than dealing with the markup directly?

Much as I like the module, CGI.pm is not an effective way to write html, and
I don't expect you'll find many who would argue otherwise. It probably
seemed like a useful feature to add once, but you're better off finding a
templating system that allows you to separate your presentation from your
code. I'm sure most people start off mixing code and print statements to
generate dynamic pages (I'll readily admit I made that mistake), but it
doesn't take long before the limitations of that approach become apparent
(usually when you have to do your first rewrite).

Matt

 

[Zebee Johnstone]

In comp.lang.perl.misc on Thu, 30 Dec 2004 14:39:21 -0500

Much as I like the module, CGI.pm is not an effective way to write html, and
I don't expect you'll find many who would argue otherwise. It probably
seemed like a useful feature to add once, but you're better off finding a
templating system that allows you to separate your presentation from your
code. I'm sure most people start off mixing code and print statements to

Text::Template works for me.

Zebee

 

[Alan J. Flavell]

Much as I like the module, CGI.pm is not an effective way to write
html,

In general I couldn't fault you on that verdict; but I nevertheless
find it well-tuned to producing the kind of HTML that's needed in and
around forms submission - which, after all, is what it's aiming at.

I'd be interested to see a working example of a templating system
that's working closely with CGI.pm. Let's say, for what I'd suppose
to be a typical example: redisplaying an inadequately-completed form
submission, with the successful inputs already filled-in for
resubmission (or for second thoughts by the user!), the erroneous
inputs flagged for correction, the mandatory fields flagged for
completion, and so forth.

 

[Gunnar Hjalmarsson]

I'd be interested to see a working example of a templating system
that's working closely with CGI.pm. Let's say, for what I'd suppose
to be a typical example: redisplaying an inadequately-completed form
submission, with the successful inputs already filled-in for
resubmission (or for second thoughts by the user!), the erroneous
inputs flagged for correction, the mandatory fields flagged for
completion, and so forth.

I believe that my contact form module is a simple example of that:
http://www.gunnar.cc/contactform/readme.html

 

[Jürgen Exner]

HTML gives you limited control. CGI provides for all the hooks
necessary for CSS, and CSS can easily be changed.

You will have to explain that statement, I am afraid.
What does CGI have to do with CSS? CGI is an interface between a web server
and server-side program.
It knows about CSS exactly as much as it knows about HMTL: nothing.

Not that either one would have anything to do with Perl in the first place.

jue

 

[Lars Eighner]

You will have to explain that statement, I am afraid.

First, I suppose you understand that "CGI" in this discussion
means the perl CGI module, not the cgi standard in general.

HTML is a markup language. It does not, and was never intended
to, give you control of the appearance of a rendered document in
any particular browser. CSS provides for making suggestions to
compliant browsers concerning presentation of HTML documents.

What does CGI have to do with CSS?

As even a casual reading of man CGI will reveal, GGI provides
for linking to a CSS stylesheet and provides for HTML tags to
have class, id, or name attributes.

CGI is an interface between a web server and server-side
program. It knows about CSS exactly as much as it knows about
HMTL: nothing.

It knows how to generate HTML tags.

It knows how to produce a link to a stylesheet and it knows how
to give html tags the identifiers a stylesheet can use.

That's all the hooks necessary for CSS.

Although "control" of the appearance of HTML documents (whether
they come from static files or are generated by CGI) is
impossible, it is possible to generate HTML with proper tags
that is linked to stylesheet, and it is easy to influence the
presentation, in so far as it can be, by editing the stylesheet,
which I would characterize as "easy" compared with trying to
effect the same things by altering the CGI program.

Not that either one would have anything to do with Perl in the
first place.

Well, folks who are using CGI.pm aren't programming in chopped
liver. And my advice to them remains: use CGI's hooks to link
to an external stylesheet and provide tags with appropriate
class, id, and/or name attributes. Exercise your influence on
presentation with the external stylesheet, and don't try to do
it with the CGI or the HTML it generates.

 

[Matt Garrish]

In general I couldn't fault you on that verdict; but I nevertheless
find it well-tuned to producing the kind of HTML that's needed in and
around forms submission - which, after all, is what it's aiming at.

It would tend to break the separation-of-presentation principle, though
(you'd have to refer back to your code to check if/where styles are being
applied on the input fields, for example).

Is that the end of the world? Probably not. My personal preference, however,
is to see as much of the html in the template file as possible. After many
years of sgml (and lately html) I tend to visualize the output better the
more I can see the tagging. Personal preference being just that, however,
I'm sure there are others that would find that sort of templating system
preferable.

Matt

 

[Lars Eighner]

In our last episode,
<[email protected]>, the lovely and
talented Matt Garrish broadcast on comp.lang.perl.misc:

It would tend to break the separation-of-presentation principle,

I suppose that depends upon whether you see html as structural
or as a presentational tool. If you think html represents the
structure of the document, then clearly the best place to apply
it is where the document is created (supposing you know what you
are creating when you create it).

though (you'd have to refer back to your code to check
if/where styles are being applied on the input fields, for
example).

I'd hope to look at the external stylesheet for that, and
having provided the hooks to CSS in the code, I'd never have to
open it up again over a presentational issue.

Is that the end of the world? Probably not. My personal
preference, however, is to see as much of the html in the
template file as possible. After many years of sgml (and
lately html) I tend to visualize the output better the more I
can see the tagging. Personal preference being just that,
however, I'm sure there are others that would find that sort
of templating system preferable.

Well, there are templates and there are templates. What some
people mean by that is slapping their <!-- insert content here
--> between the <body> and the </body> under a head that never
changes with a catch-all title. And that may be appropriate for
a one-of-a-kind sort of situation. Otherwise there are choices:
many more templates, much more sophisticated templates, or
compute the structure of the document (and import navigational
boilerplate, etc. as necessary).