[Javascript] Which submit caused the event?

[Terry Riegel]

Tedd,

For what you are working on you might want to read this article comparing various form serialization implementations.

http://jquery.malsup.com/form/comp

I used it quite heavily when I was developing my own form serialization code. Found at...

http://clearjs.org

The reason I decided to implement my own form serialization code is I couldn't find any that did it correctly. By correctly I mean that I want my javascript form serilization to be the same as what the browser would do to serialize it.

One thing you need to consider is multiple submit buttons with the same name like...

<input type="submit" name="mybutton" value="Submit">
<input type="submit" name="mybutton" value="Cancel">

the correct way to serialize this would be to only send the button that was actually clicked. Something like...

?mybutton=Submit

And to validate your frustration I spent a long time to learn that short of detecting the click event there isn't a way to determine which button triggered the form submission. It seems to me that is should be available via the onsubmit handler. I think detecting clicks is a bit hackish and just feels wrong.

Prototype gets form serialization wrong it would serialize the above code like this...

?mybutton=Submit&mybutton=Cancel

I submitted a bug fix to the prototype team quite a few years ago and thats why I decided to roll my own code.

https://prototype.lighthouseapp.com/projects/8886/tickets/672-formserialize-and-multiple-submit-buttons

Have fun,

Terry




On Jan 2, 2013, at 3:04 AM, Paul Novitski <paul at juniperwebcraft.com> wrote:

> Hi everyone, long time no post! I wish us all a fruitful year ahead~
> 
> On Tue, Jan 1, 2013 at 4:22 PM, Hassan Schroeder wrote:
>> > document.onclick=function(e){
>> >   var ev = window.event || e;
>> >   alert(ev.target.name);
>> > }
> 
> Another solution to Tedd's original problem is simply to apply an onclick event handler to each submit control that examines its value (or name) and provides that to whatever logic needs to know what's been clicked.
> 
> [By the way, I wasn't able to see Hassan's script in his original email because it was embedded in HTML and my email client ate it. Let's please provide script examples as plain text for more universal readability.]
> 
> 
> At 2013-01-01 07:48 PM, Mike Dougherty wrote:
>> > <form action="" method="post" name="myform" onsubmit="javascript:return
>> > false;" >
> ,,,
>> Should this event registration even be done in markup?  If the script tag
>> with the document.onclick registration failed for some reason, this form
>> would be completely broken.
> 
> ...Such as in any user agent not (at the moment or ever) supporting JavaScript, including some mobile devices and many otherwise entirely capable computers behind corporate and government firewalls that strip JavaScript from incoming pages. I realize the script at hand is "only" a technology example, but it's a little deflating to see 1990s coding standards on the first day of this bright & shiny new year!~
> 
> Assuming JavaScript support on public pages is rather like assuming that everyone [who matters] can climb stairs in a public building. Adding ramps to a design seems like "extra" work but the increased accessibility makes it worthwhile. Once in a while a surprising bonus is discovering that the originally-planned stairs turn out to be redundant in a well-ramped space.
> 
> 
>> Since Tedd
>> mentioned AJAX, I'm guessing he has no interest in progressive enhancement
>> or making this form fallback/work as a normal submit.
> 
> Ignoring for the moment Tedd's inline JavaScript which surely he wouldn't let escape the test bed and reach a public page, I don't think it necessarily follows that the presence of Ajax indicates an absence of progressive enhancement. We can certainly build a site in which we take people to new pages to reveal new content, then add Ajax to inject that content into the starting page when JavaScript is running. I don't use Ajax myself very much because I prefer to generate bookmarkable content, but it is possible to use Ajax to gracefully enhance a site rather than depend on it for core functionality.
> 
> Warm regards,
> 
> Paul
> __________________________
> 
> Paul Novitski
> Juniper Webcraft
> http://juniperwebcraft.com _______________________________________________
> Javascript mailing list
> Javascript at lists.evolt.org
> http://lists.evolt.org/mailman/listinfo/javascript

Terry Riegel

Put Your TimeClock on the Web
http://www.punchedin.com