Using jQuery Alerts plugin to submit a form
jQuery is awesome. The jQuery Alerts plugin is also awesome. One of the most immediate and obvious uses of the pair is presenting a spiffy confirmation box before submitting a form. For example, I recently implemented this setup on a form that ultimately deletes data. I couldn’t find a detailed example for this setup, leading to much trial and error. Here’s what worked for me.
First the form…
<form name="action_delete" action="/delete_stuff.php" method="post"> <input type="checkbox" name="option1" value="1" /> Option 1<br /> <input type="checkbox" name="option2" value="1" /> Option 2<br /> <input type="button" name="fake-submit" value="Delete" onclick="confirmDelete();" /> </form>
Take note that we are dealing with a normal form, nothing fancy about the form action, the inputs, etc. The only thing special going on here is that we’ve substituted an actual <input type="submit" ... /> button for a plain button type and attached an onclick event.
Now the JavaScript…
function confirmDelete() { jConfirm('Are you sure you want to delete this stuff?', 'Please Confirm', function(result){ if (result) { $("form[name='action_delete']").submit(); } else { return false; } }); } $(document).ready(function(){ // [ ... ] });
Assuming you understand the syntax for jQuery Alert, the confirmDelete() function is fairly straightforward. It’s everything around the jConfirm() call that gave me a headache.
Go back to the fact that we’re using a regular button and onclick, instead of a submit button and the onsubmit event. Nested jQuery functions, like jConfirm() and its third argument, have always caused me problems with normal JavaScript events, onsubmit in particular. If not done properly, the submit event is not “held up” by the confirmation dialog, input validation, etc. Such was the case here, so the only submit event occurs in the JavaScript after getting validation from the prompt.
Also note the position of confirmDelete(): outside of the jQuery “document ready” block. If you put it inside, it won’t work.
I explicitly identified the form to submit (line 4 in JavaScript) for sake of code clarity. This layout can easily be modified to dynamically process multiple forms.
Finally, note that this setup requires JavaScript to work, i.e. it does not gracefully degrade. In my opinion, the situations where this is actually a problem are limited. Every major browser on the market fully supports JavaScript, and enables it by default. Unless your target audience is 100% mobile (you should build a separate interface for your mobile app anyway) or in a high security sector, assuming its presence is a very safe bet.
Data security without software or hardware
“If not done properly, the submit event is not “held up” by the confirmation dialog, input validation”
There is another way to do this. The third argument of the jConfirm() function is just a callback. You could have defined the function with an arbitrary name (the signature of which will be specified by jConfirm) and passed the name of that function in instead. By convention however, jQuery-esque scripts always prefer to inline these things (following the Java tradition of anonymous listeners, etc.).
“Also note the position of confirmDelete(): outside of the jQuery “document ready” block. If you put it inside, it won’t work.”
Yep – if you defined confirmDelete() inside of document.ready(), then you would only be able to call confirmDelete() from within document.ready() – that’s just the nature of nested functions (which are supported by JavaScript, Python, et. a. – but not PHP as you’re used to).
Thanks, Chris. You’re right, if I un-nested all the functions, I could get all the proper
returnevents to fire and thus handle this process with a normal submit button and a call to jQuery’ssubmit(fn).However, that code is (a) a bit longer and (b) not as flexible when it comes to adding more jQuery magic to the mix.
As for the function scope of confirmDelete(), I was just keeping things simple, as most readers simply want a working solution. However technical background is always a good thing. Thanks for covering for my laziness.
Frank – certainly most folks who find this information most useful are those in search of a turn-key solution to jQuery form submissions – and for that, the text does it’s job well. That said, I have yet another comment…
“not as flexible when it comes to adding more jQuery magic to the mix.”
And you’re absolutely right… that is… it’s not as flexible *at this altitude.* A level higher (or lower, you could make the case) on the abstraction ladder, and you’d find many ways to utilize a non-inlined callback for the form submission. But… then the argument becomes an architectural brow-beating, and not one of just getting the job done already.
At any rate, for the up-and-coming, jQuery-using crowd, you present several core concepts of jQuery form and function while at the same time applying the lessons to a real example – and that’s just cool.
at this altitude
Good qualifier, but you hit the nail on the head with “getting the job done already.” Combinations of HTML, CSS, and JavaScript often present several routes to the same solution. My rule of thumb has become “Does it work? In all browsers? Good, moving on.”