Forms and submit buttons

Discussion in 'HTML' started by nettleby@googlemail.com, Apr 17, 2006.

  1. Guest

    I'm just learning about forms and the submit process. One thing I'm
    confused about is: if there are two submit buttons on a page, then is
    it necessary to have a name for both buttons, or just for one, in order
    that the server can differentiate between the buttons?

    for example:

    <form action="http://www.htmlcodetutorial.com/cgi-bin/mycgi.pl">
    Firstname:<input type="text" name="fname">
    <br>
    Surname:<input type="text" name="sname">
    <br>
    <input type = "submit" value="Update"/>
    <input type = "submit" value="Reset" name = "reset"/>
    </form>

    You would get two different strings being submitted here, for the two
    buttons. Is this a valid way of doing things?

    Thanks
     
    , Apr 17, 2006
    #1
    1. Advertising

  2. wrote:
    > I'm just learning about forms and the submit process. One thing I'm
    > confused about is: if there are two submit buttons on a page, then is
    > it necessary to have a name for both buttons, or just for one, in order
    > that the server can differentiate between the buttons?
    >
    > for example:
    >
    > <form action="http://www.htmlcodetutorial.com/cgi-bin/mycgi.pl">
    > Firstname:<input type="text" name="fname">
    > <br>
    > Surname:<input type="text" name="sname">
    > <br>
    > <input type = "submit" value="Update"/>
    > <input type = "submit" value="Reset" name = "reset"/>
    > </form>


    In your example your reset button should be:

    XHTML
    <input type="reset" value="Reset" />

    or HTML
    <input type="reset" value="Reset">

    >
    > You would get two different strings being submitted here, for the two
    > buttons. Is this a valid way of doing things?


    If you have more than one submit button if you five them different names
    then your receiving script can "see" which button was activated and
    process accordingly

    <input type="submit" value="Do One Thing" name="do_this">
    <input type="submit" value="Do Something Else" name="do_that">

    so if the 1st submit button was click the receiving script would see
    this key value pair:

    do_this="Do One Thing"

    or with the second

    do_that="Do Something Else"

    HTH

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, Apr 17, 2006
    #2
    1. Advertising

  3. On Mon, 17 Apr 2006, Jonathan N. Little wrote:

    > If you have more than one submit button if you [g]ive them different
    > names then your receiving script can "see" which button was
    > activated and process accordingly
    >
    > <input type="submit" value="Do One Thing" name="do_this">
    > <input type="submit" value="Do Something Else" name="do_that">
    >
    > so if the 1st submit button was click the receiving script would see
    > this key value pair:


    Right; but in real life it's more complicated than that, because there
    are situations where forms get submitted without the user activating
    any of the submit buttons, and the server side process needs to be
    ready to cope with that.

    Might I suggest my own page on the topic? Although I admit it hasn't
    been extensively updated recently, I think it's still fairly close to
    reality: http://ppewww.ph.gla.ac.uk/~flavell/www/trysub.html

    regards
     
    Alan J. Flavell, Apr 17, 2006
    #3
  4. Guest

    Jonathan N. Little wrote:

    >
    > <input type="submit" value="Do One Thing" name="do_this">
    > <input type="submit" value="Do Something Else" name="do_that">
    >
    > so if the 1st submit button was click the receiving script would see
    > this key value pair:
    >
    > do_this="Do One Thing"
    >
    > or with the second
    >
    > do_that="Do Something Else"
    >


    Hi, Thanks for the reply.

    I understand that if I used unique name/value combinations to identify
    the buttons then it will work as you've described. What I was
    interested in is if a default submit button doesn't have a name defined
    at all, then wouldn't you still be able to differentiate at the server
    end between that and another (e.g. reset) button if that did have a
    name defined. I figured that the submit button wouldn't pass any data
    from the button, but the reset button would, if pressed.


    Thanks,

    Debbie
     
    , Apr 17, 2006
    #4
  5. Guest

    Coincidentally, I'd already read your page as part of my research: it
    got returned near the top of a Google search I did :) It was very
    helpful, thanks, and I'd bookmarked it.

    My question was more of a hypothetical scenario, to discover if it was
    possible to get no name/value data transmitted for a web page submit
    button.

    Thanks,

    Debbie
     
    , Apr 17, 2006
    #5
  6. JDS Guest

    On Mon, 17 Apr 2006 04:25:41 -0700, nettleby wrote:

    > You would get two different strings being submitted here, for the two
    > buttons. Is this a valid way of doing things?


    No you would not.

    The server will only "see" the button that was pressed.

    Did you try it before you posted this question?
    Did you Google about this question before posting?

    etc.

    Not to be crass, but this question can easily be answered by some simple
    self-help such as a Web search, book, or trying it out to see what happens.

    later...!

    --
    JDS | lid
    | http://www.newtnotes.com
    DJMBS | http://newtnotes.com/doctor-jeff-master-brainsurgeon/
     
    JDS, Apr 17, 2006
    #6
  7. Guest

    JDS wrote:
    > On Mon, 17 Apr 2006 04:25:41 -0700, nettleby wrote:
    >
    > > You would get two different strings being submitted here, for the two
    > > buttons. Is this a valid way of doing things?

    >
    > No you would not.
    >
    > The server will only "see" the button that was pressed.
    >
    > Did you try it before you posted this question?
    > Did you Google about this question before posting?


    Yes to both, and read at least two books!

    When I try my code, I can tell the difference between the submit and
    reset button being transmitted to the cgi validation page I'm using.
    I've coded it so the submit button doesn't have a name, and the reset
    button does.

    code is at:
    http://www.debsweb.co.uk/test1.htm


    In practice, when the submit button is clicked, then there is no data
    transmitted for the button, obviously, as there is no name. When the
    reset button is clicked, then the appropriate name/value pair is
    transmitted. I would have thought this meant the server end could
    differentiate between the two buttons, as long as it's aware of the
    design of the page? (Leaving aside the complications of the Enter key
    being pressed.)


    Debbie
     
    , Apr 17, 2006
    #7
  8. JDS Guest

    On Mon, 17 Apr 2006 11:05:30 -0700, wrote:

    > In practice, when the submit button is clicked, then there is no data
    > transmitted for the button, obviously, as there is no name. When the
    > reset button is clicked, then the appropriate name/value pair is
    > transmitted. I would have thought this meant the server end could
    > differentiate between the two buttons, as long as it's aware of the
    > design of the page? (Leaving aside the complications of the Enter key
    > being pressed.)


    Hi.

    You can do it one of two ways:

    (1) Unique button names

    or

    (2) unique button values

    or

    (3) both

    The way Jonathan N Little suggested was with unique button names.

    Personally, I don't see the point, and I think using method (2) makes it
    harder to code stuff on the server. If you have two submit buttons, it
    doesn't matter what they are named (named the same or differently), the
    server only ever sees the buton that was pressed. It is as simple as that.

    HOWEVER, in answer to (one of) your question(s), "no". You *MUST* have a
    name for the button for the server to know what it is.

    Additionally, the server has absolutely no idea about the "design of the
    page". Not sure what you mean by that.

    It works like this:

    (1) There is an HTML form

    (2) The Web server gets some data passed to it from the form in a specific
    format.

    (3) a "script" or program of some kind gets the information sent to it in
    roughly the same format, and then does "something" with the data.

    The server and the script on the server don't know *ANYTHING* at all about
    the HTML page. All they see, in a vacuum, is some specifically-formatted
    data. Because of this vacuum, you must make sure that your HTML form is
    set up properly to send all of the data that the server is going to need.
    And this proper set up includes giving your submit button(s) a name.


    Still stuck? Please ask more.

    later...

    --
    JDS | lid
    | http://www.newtnotes.com
    DJMBS | http://newtnotes.com/doctor-jeff-master-brainsurgeon/
     
    JDS, Apr 17, 2006
    #8
  9. Guest

    I'm still confused, I'm afraid. I have read that you must do it in one
    of those two ways. I'm happy enough doing that, no problem, but would
    like to appreciate the technicalities more.

    I've never written any server side code to process these forms (maybe
    this is where my problem lies!) I have, however, written protocols in
    C++ and other languages.

    If I wanted a custom data input via a server, to a database or file,
    say, with perhaps some custom data manipulation and/or checking, then
    I'd need to ensure that the server knew what to do with my data.
    (That's what I mean by the design of the page.)

    If I was writing my own server script to accept the data from my page,
    then wouldn't I just be able to take a default route for the submit key
    in my example code (i.e. no data), and only action the reset button as
    necessary if it were present?

    I know I'd be able to do this in C++ easily. It puzzles me that the two
    ways you reference are cited as the only way of doing it. There may be
    other reasons I'm not aware of, I guess?

    Debbie
     
    , Apr 17, 2006
    #9
  10. JDS Guest

    On Mon, 17 Apr 2006 12:03:47 -0700, debbie.games wrote:

    > If I was writing my own server script to accept the data from my page,
    > then wouldn't I just be able to take a default route for the submit key
    > in my example code (i.e. no data), and only action the reset button as
    > necessary if it were present?
    >
    > I know I'd be able to do this in C++ easily. It puzzles me that the two
    > ways you reference are cited as the only way of doing it. There may be
    > other reasons I'm not aware of, I guess?
    >



    Huh? Do what in C++? How would you do it?

    In answer to the first paragraph I quoted from your post: NO. There is no
    "default action".

    If you do not give the submit button a name, then the server won't see it
    and thus won't be able to do anything with it.

    Check out this example:
    http://engineering.jhu.edu/~jeff/default-submit-button.php

    Note how when you click "Submit Me", a value shows up for the submit
    button, but clicking on the other submit button, "This button has no name
    attribute", there is no value for ANY submit button.

    Also, note how the checkboxes only supply data to the server IF THEY ARE
    CHECKED! If not checked, then NOTHING goes to the server. Not a value of
    "not checked" -- nothing. The server has no idea that the checkboxes were
    even on the form at all!!

    And lastly, note that this behavior as described with the checkboxes does
    not apply to the TEXT boxes because when a blank text box is submitted,
    the server always sees it as an empty text box. A form field that is not
    filled in. Not the same as with check boxes (or radio buttons or several
    other HTML Form components)

    Still stuck? ask more...


    later...

    --
    JDS | lid
    | http://www.newtnotes.com
    DJMBS | http://newtnotes.com/doctor-jeff-master-brainsurgeon/
     
    JDS, Apr 17, 2006
    #10
  11. Debbie Guest

    I'm sorry, I don't think I'm explaining myself very well, I'll try and
    expand upon my thinking.

    The example I was working with uses the get method to post the form,
    which transmits the data in string form to the url, and then will get
    decoded by the server script.

    The only way the form can get posted (apart from the enter key) is by
    pressing either the submit button or the reset button.

    If the string arrives with no data for the submit button, then my
    custom code would know that it must have been the submit button that
    was pressed, not the reset button. There is no ambiguity in the data
    transmitted. Likewise, if the reset name/value pair is present then it
    can't have been the submit button being pressed: it must have been the
    reset button.

    I haven't read up on the issues regarding the enter key, which may
    explain why you'd need the name/value pair, but I know you certainly
    don't need a name for a submit button if it's the only button on the
    form.

    Debbie
     
    Debbie, Apr 17, 2006
    #11
  12. JDS Guest

    On Mon, 17 Apr 2006 12:28:10 -0700, Debbie wrote:

    > If the string arrives with no data for the submit button, then my
    > custom code would know that it must have been the submit button that
    > was pressed, not the reset button. There is no ambiguity in the data
    > transmitted. Likewise, if the reset name/value pair is present then it
    > can't have been the submit button being pressed: it must have been the
    > reset button.
    >
    > I haven't read up on the issues regarding the enter key, which may
    > explain why you'd need the name/value pair, but I know you certainly
    > don't need a name for a submit button if it's the only button on the
    > form.


    Okay, now that makes sense. At least, the processing logic makes sense.
    To me, however, and based on my experience, it is not a Good Idea(TM) --
    apart from making sense or not.

    Personally, I have found that it can be very hard to remember What You Are
    Doing(TM) with respect to programing or scripting. I think that the logic
    steps you discuss here can much more easily lead to losing track of What
    Is Going On(TM) than can giving every form component a clearly
    understandable name.

    Personally, I try to give every variable, function, form component, etc.,
    an easily recognizable name, and I am not afraid to make these names
    rather long in the interest of clarity. I have been known to name things
    like "process_the_form_component_for_submission_into_the_database()" or
    "left_hand_navigation_component" rather than "process()" or "lhnc" or
    similarly obtuse names.

    My point is merely that even though you don't *need* a name, according to
    your logic, you *should* use a name anyways.

    Lastly, why are you even asking this question in the first place?

    --
    JDS | lid
    | http://www.newtnotes.com
    DJMBS | http://newtnotes.com/doctor-jeff-master-brainsurgeon/
     
    JDS, Apr 17, 2006
    #12
  13. Debbie Guest

    Lastly, why are you even asking this question in the first place?


    Because if someone tells me I can't do it, but can't back up why not, I
    like to find out for myself. There may be good reasons for doing things
    a certain way, but I like to know what they are rather than accept
    things without question. Thanks for the replies.

    Debbie
     
    Debbie, Apr 17, 2006
    #13
    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. The Crow
    Replies:
    2
    Views:
    4,403
    Bruce Barker
    Sep 27, 2005
  2. Replies:
    4
    Views:
    937
  3. Harry
    Replies:
    3
    Views:
    374
    Harry
    Jan 12, 2006
  4. sandyde2
    Replies:
    2
    Views:
    182
    sandyde2
    Oct 2, 2003
  5. Paul M
    Replies:
    1
    Views:
    131
    Lasse Reichstein Nielsen
    Oct 15, 2003
Loading...

Share This Page