Multiple submit actions.

Discussion in 'Perl Misc' started by sam, Dec 28, 2004.

  1. sam

    sam Guest

    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
     
    sam, Dec 28, 2004
    #1
    1. Advertising

  2. 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
     
    Jürgen Exner, Dec 28, 2004
    #2
    1. Advertising

  3. sam

    sam Guest

    Jürgen Exner wrote:

    > 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

    > jue
    >
    >
     
    sam, Dec 28, 2004
    #3
  4. sam wrote:

    > 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?"
     
    Chris Mattern, Dec 28, 2004
    #4
  5. sam

    Lars Eighner Guest

    In our last episode, <cqr57k$1ld7$>, the lovely
    and talented sam broadcast on comp.lang.perl.misc:

    > 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.

    --
    Lars Eighner http://www.io.com/~eighner/
    I hate laundry month.
     
    Lars Eighner, Dec 28, 2004
    #5
  6. sam wrote:

    > 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--

    --
    Cocoa programming in Perl: http://camelbones.sourceforge.net
    Hire me! My resume: http://www.dot-app.org
     
    Sherm Pendley, Dec 28, 2004
    #6
  7. sam

    sam Guest

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

    Thanks
    Sam.

    sam wrote:
    > 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
     
    sam, Dec 28, 2004
    #7
  8. sam <> wrote:

    > 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?


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
     
    Tad McClellan, Dec 28, 2004
    #8
  9. sam

    sam Guest

    Tad McClellan wrote:

    > sam <> wrote:
    >
    >
    >>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?
    >
    >

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

    Thanks
    Sam
     
    sam, Dec 28, 2004
    #9
  10. sam

    Lars Eighner Guest

    In our last episode, <cqruuc$21t7$>, the lovely
    and talented sam broadcast on comp.lang.perl.misc:

    > 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.

    --
    Lars Eighner http://www.io.com/~eighner/
    Health is merely the slowest possible rate at which one can die.
     
    Lars Eighner, Dec 28, 2004
    #10
  11. sam

    Guest

    Jürgen Exner wrote:
    > 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.
     
    , Dec 30, 2004
    #11
  12. sam

    Lars Eighner Guest

    In our last episode,
    <>,
    the lovely and talented
    broadcast on comp.lang.perl.misc:


    > Jürgen Exner wrote:
    >> 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.


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

    --
    Lars Eighner http://www.io.com/~eighner/
    College: The fountains of knowledge, where everyone goes to drink.
     
    Lars Eighner, Dec 30, 2004
    #12
  13. sam

    Matt Garrish Guest

    "Lars Eighner" <> wrote in message
    news:...
    > In our last episode,
    > <>,
    > the lovely and talented
    > broadcast on comp.lang.perl.misc:
    >
    >
    >> Jürgen Exner wrote:
    >>> 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.

    >
    > 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
     
    Matt Garrish, Dec 30, 2004
    #13
  14. In comp.lang.perl.misc on Thu, 30 Dec 2004 14:39:21 -0500
    Matt Garrish <> wrote:
    >
    >
    > 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
     
    Zebee Johnstone, Dec 30, 2004
    #14
  15. On Thu, 30 Dec 2004, Matt Garrish wrote:

    > 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.
     
    Alan J. Flavell, Dec 30, 2004
    #15
  16. Alan J. Flavell wrote:
    > 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

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    Gunnar Hjalmarsson, Dec 30, 2004
    #16
  17. Lars Eighner wrote:
    > 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
     
    Jürgen Exner, Dec 30, 2004
    #17
  18. sam

    Lars Eighner Guest

    In our last episode, <Hm0Bd.21564$rL3.1518@trnddc03>, the lovely
    and talented Jürgen Exner broadcast on comp.lang.perl.misc:

    > Lars Eighner wrote:
    >> 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.


    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.

    --
    Lars Eighner http://www.io.com/~eighner/
    War hath no fury like a noncombatant.
    - Charles Edward Montague
     
    Lars Eighner, Dec 31, 2004
    #18
  19. sam

    Matt Garrish Guest

    "Alan J. Flavell" <> wrote in message
    news:p...
    > On Thu, 30 Dec 2004, Matt Garrish wrote:
    >
    >> 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.
    >


    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
     
    Matt Garrish, Dec 31, 2004
    #19
  20. sam

    Lars Eighner Guest

    In our last episode,
    <Eq3Bd.45629$>, the lovely and
    talented Matt Garrish broadcast on comp.lang.perl.misc:


    > "Alan J. Flavell" <> wrote in message
    > news:p...
    >> On Thu, 30 Dec 2004, Matt Garrish wrote:
    >>
    >>> 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.
    >>


    > 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).

    --
    Lars Eighner http://www.io.com/~eighner/
    "Shhh! Be vewwy, vewwy quiet! I'm hunting Muswims!"
    - President Elmer Bush
     
    Lars Eighner, Dec 31, 2004
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark
    Replies:
    1
    Views:
    1,798
  2. Ice
    Replies:
    4
    Views:
    6,269
    David Dorward
    Nov 2, 2003
  3. Replies:
    4
    Views:
    1,014
  4. Just Me
    Replies:
    4
    Views:
    400
    Steve C. Orr [MCSD, MVP, CSM, ASP Insider]
    May 8, 2007
  5. Sophisticado

    Need Help w/Multiple form submit actions

    Sophisticado, May 1, 2005, in forum: Javascript
    Replies:
    1
    Views:
    157
    David Dorward
    May 1, 2005
Loading...

Share This Page