views:

216

answers:

3

I'm working on the Web GUI of an appliance-like product.

I have an HTML form that works fine: it shows a list of things with checkboxes, the user checks some of them and clicks the "remove" button which submits the form. The server gets the POST, removes the items, and refreshes the page. All fine.

There's a requirement to add an "are you sure?" confirmation to the form. If I add a call to

 confirm("are you sure?");

as the onsubmit method in the FORM tag, or the onclick in the submit button tag, it works fine but uses the ugly browser-native confirm dialog.

Elsewhere in the product we have a nice custom CSS-styled confirm dialog I'd like to use, but it works like this: At the appropriate place, you put a call to

myConfirm("Confirm", "Are you sure", "Yes", "No", confirmCallback);

This puts up a clickmask, customizes a dialog, centers and displays it, and then returns FALSE and the form doesn't submit.

Later when the user decides, if they press "Yes", it calls the confirmCallback function. In the other, Ajax based pages of the product this gathers info, creates a postBody and uses Prototype's Ajax object to post it, and all is fine. (If "No", then the dialog and clickmask are removed and things continue.)

On this simpler page, with the pure HTML form, I have a confirmCallback function that looks like this:

var confirmCallback = function() {
    document.myForm.submit();
}

and it fires OK, but when the form is submitted, the remove button has ALREADY been clicked, and the false returned by the custom confirm suppressed submission. Instead, this is considered a new submission, and the remove button was not actually clicked, so it is not considered "successful" in terms of W3.org's HTML 4 standard section 17.13.3. The server gets the data, no remove button, says "I got it but I dunno what you want me to do with it" and just does nothing but serve the next page.

If you're read this far, THANK YOU, and here is my actual question. How can I, in my confirmCallback javascript function, in a crossbrowser manner, cause the remove button to fire, become "successful" and submit along with the rest of the data?

A: 

In your callback, remove the onclick handler for the button (causing the confirmation), then trigger a click on the button. This will cause the button click to submit the form and result in the button causing the submit to be posted back along with the form data.

var confirmCallback = function() {
    $('submitButton').stopObserving('click');
    $('submitButton').click();
}
tvanfosson
Hm, interesting. I will try that. Thanks.
Berry
OK. Pro: form is no longer submitted without the button. Con: form is no longer submitted at all.This seems to be the right approach though; I will fiddle with it some more and report if I get it to work.
Berry
Could be fire doesn't do what I'm expecting in Prototype. I've moved to jQuery and my memory is a little hazy. You might need to get the underlying element and click() it.
tvanfosson
According to http://www.w3schools.com/htmldom/dom_obj_button.asp it works in IE since v4, FF since v1, and Opera since v9.
tvanfosson
I also just confirmed that it works in Safari 4.
tvanfosson
A: 

Assuming that the remove button is the submit button for that form then probably the easiest solution is to give the form an id

<form id="submitForm"...

Then in your confirm call the form submit

document.getElementById("submitForm").submit()

I think that will do what you're asking but it seems like you were pretty much at that solution already so if you're asking something else let me know.

stimms
That is pretty much what I'm doing; the problem is by the time my callback is called the form has "reset" and doesn't consider the submit button "clicked" any more, and the server doesn't see it in the POST data. THanks for answering, though.
Berry
A: 

Sounds like you're gonna need a hidden field to pretend to be the pressed button, and each button will require no name, but instead an onclick event to manipulate the value of the hidden field.

If the name of the buttons are all different, you might need to use DOM methods to add the hidden field because I don't think you can change the name of a field once it has been added to the DOM in all browsers.

If you require this solution to still work without JS, then you may need play around with the JS logic a little more (to do more modifications to your initial DOM tree) or modify the server code. You could even put the "Are you sure" behaviour into the response then...

Lee Kowalkowski
Thanks Lee; that's exactly what I wound up doing. As it happens, for this product we need not consider the "no JS" case, so I'm good to go!
Berry