Using Multiple Submit Buttons With A Single Form

After a while of web development, developers usually come across a project where they need to create multiple submit buttons with a single form. This usually occurs right when they have a table that has several rows and each row has a couple buttons to edit or delete the row. These rows might have been added dynamically using JavaScript or they could have been simply created sever-side as the table is generated from a list of records in a database. When one of the buttons is clicked, you usually need to know what button was clicked and take an action on it. In this post we will take a look at 4 different ways to handle this scenario and what the pros and cons are to each. Let’s get started!

Option 1 – Buttons With Same Name, Different Text

This solution involves creating several input elements with the type being set to “submit”. Their “name” attribute is also the same for all the buttons and the value of the button, which is what users see, is usually different. Here is an example of that…

<input type="submit" name="submit_button" value="Update1">
<input type="submit" name="submit_button" value="Update2">
<input type="submit" name="submit_button" value="Update3">

Here you see we have three submit buttons, all with the same name “submit_button” but with different values. When the user sees this form, they see the “Update1”, “Update2” and “Update3” labels. When submitted, the clicked button value is placed in the “submit_button” name and you can compare the value to know which button was clicked.

• Pros:
  1. Usually easy to implement, especially if the buttons were added dynamically (through something like JavaScript)
  2. works for older browsers (IE 9 and below usually)
• Cons:
  1. Not at all internationally friendly. What if you wanted the form in Spanish? Update1 could be Spanish and you would have to check for the Spanish equivalent.
  2. Also each button has to have a different text value. You couldn’t name all three “Update” and expect to know which one was clicked.

Option 2 – Different Names For Each Button

The next solution involves using a different name for each of the buttons. Much like the first solution, this involves using an input type of submit. Here is an example of how this might work…

<input type="submit" name="update_button1" value="Update">
<input type="submit" name="update_button2" value="Update">
<input type="submit" name="delete_button" value="Delete">

Here we have a couple of update buttons and a delete button. Depending on which one is clicked, the server-side script can see a different name submitted (and only one is submitted). So in one case you may see “update_button2” as an element in the POST array and another time you may see “update_button1”. But never “update_button1” AND “update_button2” together.

• Pros:
  1. Internationally friendly because now the button values could be any language. The name is what you would look at in your script.
  2. They can also have the same text (like shown in the example above. We see two “Update” buttons and this is fine. Again works for older browsers.
• Cons:
  1. Big drawback is now you have to detect if any of these names are in the submission. You have to check if update_button1 is in the submission or is it update_button2 or is it delete_button? The server-side logic here can get tedious and lead to spaghetti code.
  2. The names also have to be unique so this may lead to complex logic for those scripts wanting to create the buttons dynamically. You may find yourself using a loop and creating names like “update1”, “update2″… “updateN”.

Option 3 – Use Button Element with Same Name With Different Supplied Value

Here we take a different approach and instead of using the input element we use a button element. Here we can get some flexibility that seems to solve a lot of previous issues. Here is an example of that…

<button type="submit" name="action" value="update1">Update</button>
<button type="submit" name="action" value="update2">Update</button>
<button type="submit" name="action" value="delete">Delete</button>

Here these buttons will act like a submit button. However, they share the same name and have different values. As you probably can tell, this still solves many of the issues of the other solutions. Let’s take a look at the pros and cons of this…

• Pros:
  1. Internationally friendly because the button text can be any language. That text is not what is submitted, it is what is in the value attribute.
  2. This is also easy to add dynamically as the only thing that needs to be different is the button value attribute. Again you have to make sure these are unique, but being that the user doesn’t see these it ok to do something like appending a row number. It has the same name, so this is all you have to look for. Clicking the second update button will lead to “update2” being the value of “action” in the POST submission. Also works fine in older browsers.
• Cons:
  1. As mentioned the only real drawback, a minor one, is that the values of each button still has to be unique and so if generated dynamically you have to make those values are unique. Appending a row number or ID should work nicely. Just read the “action” POST value and break off the ID/Row from the value. If the values are not all similar, then you still have to detect what value “action” has.

Option 4 – Using Formaction Attribute (Just a Mention)

Now I don’t really consider this a solid solution to posting to the same form with multiple buttons because this formaction attribute overrides the action attribute of the form. This causes the submission to be sent to a different location. Now the only reason I am mentioning this solution in the context of this article is that it is fairly new and can be used to at least determine which button was clicked because it goes to a different URL. Our example…

<button type="submit" name="action" formaction="/update1">Update</button>
<button type="submit" name="action" formaction="/update2">Update</button>
<button type="submit" name="action" formaction="/delete">Delete</button>

If the user clicks the first update button, they will submit the form to the /update1 URL. If they click the second update, they will send the form submission to /update2 URL. So as you can see we are not really submitting the buttons to the same form action and thus doesn’t quite hit the nail on the head when it comes to submitting the values to some server-side processing script.

Lets see some pros and cons of this…

• Pros:
  1. Internationally friendly as before since the button text can be any language. Great if you want the buttons to submit to different URLs like REST endpoints perhaps.
  2. Again fairly easy to add these buttons dynamically.
• Cons:
  1. Not really submitting values to the same server-side script. If you expect one form “handler” script to process the form, then this solution just doesn’t work.
  2. Requires you to have multiple form submission destinations.
  3. Formaction is also fairly new, so doesn’t work on browsers like IE9 and below.

What is the best?

Honestly I think option 3 is really the best in most situations. It offers the most flexibility in that the buttons can be easily generated programatically if desired, you can check out the same name on the server-side script and is internationally friendly if you want to change the text on buttons. I have seen some proponents of the formaction attribute recently, but again it doesn’t really answer the direct question if you want one simple handler script for your form. So give option 3 a try and if you don’t like that, you can possibly fall back on option 1. Option 2 is really the only one I wouldn’t advise in that it really makes the server-side script a bit brittle and hard to scale. If you know you will only have less than 4 or 5 buttons, you could get away with it.

I hope this answered your questions around multiple submit buttons for a single form and hope you find them useful. Thanks again for reading! 🙂