Consider a simple form with 2 submit buttons
<form method="post">
<button type="submit" name="command" value="cancel">Cancel Order</button>
<button type="submit" name="command" value="proceed">Save Order</button>
</form>
Once submitted, the server will know which submit button was used to submit the form by checking the value for command. Great!
In this case, I am using the onsubmit event handler of the form to preprocess and send the form data via AJAX. Like this: <form method="post" onsubmit="return ajaxSubmit(this);">
I’m using this ajaxSubmit function as a general way to check through any supplied form’s elements and send the data via Ajax instead. This works fine for determining the value of text fields, if checkboxes are “checked”, which radio is selected in a group, etc. The only thing it seems to get wrong (because I’m not sure how to check this) is which submit button was used to submit the form. i.e There is nothing in myForm["command"] to tell which of the 2 command buttons was actually used.
Instead, is there a way to access the same ‘post’ data that the server receives with JavaScript before it is sent?
Otherwise, is this just a flaw I need to work around? What’s the best way?
Edit:
Since all modern browsers will pass the name/value of the button used to submit the form (along with the other relevant parts like which option is selected from a group, checked checkbox name/values, etc.) can anyone explain why there is no way to access this data directly before it is sent to the server? Is there a reason why we shouldn’t be able to?
Not that exact data, no.
The usual way to know which
submitbutton was pressed is (unfortunately) to attachclickhandlers to the buttons and have them set a variable (or the value of ahiddenfield), which you can then check in yoursubmitevent handler.Since you’re using old-style DOM0 event handler attributes, probably the
hiddenfield fits better with what you’re doing:…where
submitClicklooks like this:…but I do recommend looking into using DOM2-style event handlers instead, or at least attaching DOM0 handlers in code blocks, as you can avoid creating global functions, share data without creating global variables, etc.
Just to be clear, you don’t have to specify an
onclickattribute on every element, the only reason I did that above is because you were using DOM0 handlers.The better way to handle it is with event bubbling. Since the
clickevent bubbles up to the form from its descendant controls, including the submit buttons, you can hook the event on the form and then look to see if it occurred on a submit button and, if so, what that button’svalueis.For instance, here with a DOM0 handler, attached dynamically to the form, which will alert the value of the submit button clicked:
Live Example | Source
Or using DOM2 handlers on any modern browser (not IE8 or earlier, but it would be easy to add
attachEventfor those, which does much the same thingaddEventListenerdoes [and predates it]):Live Example | Source
Or using a library to make it easier (here it’s jQuery, but most of them have this feature, which is called event delegation):
Live Example | Source (I’m using
delegatethere because I like the clarity; with recent versions of jQuery, you could use the hyper-overloadedon, but it’s less clear. If you choose to, note that the order of arguments is different.)The point here being that it’s not complicated, difficult, or particularly cumbersome.
Re your ending question of your edit:
Probably not, no. It’s important to understand that a lot of this stuff just evolved. The submit button’s value being sent with the form is an HTML thing, apparently when doing the DOM HTML forms module, it just didn’t occur to anyone to say “Hey, we should have a property on the form that only exists during the form submission event that tells you what submitted the form.” It probably should have occurred to someone, but apparently, it didn’t.