Problem in doSubmitAndLock()

Hey Jake, I need your input on this (This is fairly complicated, so 
holler if its not clear)...

Back in October, I made the following change:

    csc_102604_1 - Discovered that when Barracuda submits a form using
    doSubmitAndLock(), the onsubmit form handler was not actually
    getting invoked. Changed so that it is manually invoked now, making
    it easy to patch in validation code, etc, which will get run before
    the form is submitted. As expected, returning false vetoes the
    submission.

In this, I changed FormControl.js (see the //csc_102604 tag below). Now 
the purpose of this change was to make sure that when a submit button is 
pressed, the form's onSubmit() function gets called (giving the 
developer a change to veto an action simply by coding a javascript 
handler into the form's onsubmit function. So when the user presses a 
submit button, we fall into this code here and the onsubmit handler is 
invoked, and then if that returns true, we go ahead and submit the form. 
KEY POINT: for submit buttons, this is where the form submission 
actually happens!

On, now, on October 27, 2004 (one day later), it looks like you 
submitted a change which modified this (and for some reason this isn't 
documented in A_Changes_History):

    Made further fixes to FormControl.js.  Also had to modify
    HTMlActionRenderer so that it doesn't put "return false;" in the
    onsubmit attribute of the form, otherwise the new changes to
    FormControl.js render the form unsubmitable. Hopefully this doesn't
    break other areas like back button disabling, but the way things
    were, forms couldn't be submitted at all.  The current behavior
    should be correct and anything broken because of this fix should be
    fixed to work with this fix.

The change in FormControl was to add one line:

        //loop through other arguments which are expected to be 
functions, but
        //we'll double check anyway and ignore each argument that isn't a
        //function
        var ok = true;
        for (var i=1; i < args.length; i++) {
            if (args[i].call) {
                ok = args[i].call(null, args[0]);
Jake-->   if (ok == undefined) ok = true; //account for methods with no 
return value
                if (!ok) break;
            }
        }

//csc_102604_1_start - programatically invoking submit does NOT 
automatically call
//the onsubmit function - so we want to manually invoke that handler
//        if (ok) args[0].submit();
        if (ok) {
me-->   var ok2 = (args[0].onsubmit) ? args[0].onsubmit() : true;
me-->   if (ok2!=false) args[0].submit();
        }

I haven't tracked down exactly what changed in HTMLActionRenderer yet. 
And I'm not entirely clear why you made your change above (but I'm sure 
you'll make that clear). SO...let me see if I can explain the problem 
now. Basically the idea here was that if you have a form like this:

<form action="DoSomething.event" method="POST" name="SomeForm"  
onsubmit="alert('Hi Mom!'); return true;">
    <input type="text" size="10" name="SomeField1">
    <input type="text" size="10" name="SomeField2">
    <input class="button" type="button" value="Revert"
               
onclick="this.form.action='pt_DoRevertUser.event.param_map';return 
doSubmitAndLock(this.form,cshl_SubmitAndReplace);" >
    <input class="button" type="submit" value="Ok" name="el_32734193"
               onclick="this.form.action='DoLoginSwitch.event';return 
doSubmitAndLock(this.form);">
</form>

When the user presses the submit button, the method return 
doSubmitAndLock(this.form) gets invoked, which in turn would fall 
through into the SECOND block of code in FormControl.js and then 
manually invoke submit() on the form. My original modification tweaked 
that so the onsubmit function would get invoked first. Now, this was 
working fine for me (and for submit buttons), but evidently, it broke 
something for regular input buttons (which is what you were trying to 
fix I think).

Ok, so what I have discovered now is that when you press the Revert 
button, doSubmitAndLock(this.form,cshl_SubmitAndReplace) gets invoked, 
which actually gets processed in the FIRST block of FormControl.js. I 
don't think I realized this when I made my original change. At any rate, 
what happened is that the form actually gets submitted in that first 
block, and because cshl_SubmitAndReplace did not return a value, ok 
would be undefined and the second block would get skipped altogether. 
This meant the onsubmit function didn't get invoked, but the form still 
submitted properly.

Now, when you added your check for undefined, what happened is that by 
changing the value to true you cause it to fall into the second block as 
well, which means that the form gets submitted twice - submit 1, call 
onsubmit(), then submit 2. And it was this dual submission that was 
breaking the client side redirects that are supposed to happen 
automatically when a BSelect changes or a regular button is pressed.

So basically, that describes the problem. What happens now is that when 
you press a regular button, the form gets mapped through ParamGateway, 
and a response gets written back out to the client, but because a second 
submit happens, it effectively clears the ParamGateway cid parameter 
(that's not part of the "submitted form" which happens as a result of 
the form.submit()) and so the code that redirects the client back to the 
results can't get to where it needs to go. (that paragraph was a little 
confusing).

At this point, here's what I need to know from you...

1. should we really have the submit happening in 2 different places in 
FormControl.js? (probably yes)
2. if that's the case, we probably want to ensure that if the form gets 
submitted in the first block then it SHOULDN'T get submitted again a 
second time, right?
3. should the form's onsubmit handler get called for both submit buttons 
and regular buttons? Or only submit buttons? I'm inclined to say "both"
4. I'm wondering if I should move my logic to invoke "onsubmit" up above 
both of the blocks - so that that is the very first thing done? then we 
could fall into both of the blocks down below... (and this would allow 
us to remove your undefined check as well)

Thoughts? Suggestions?

I'll be watching for your response...
Christian

-- 

Christian

------------------------------------------------------------------------
Christian Cryder
Internet Architect, ATMReports.com <http://atmreports.com>
------------------------------------------------------------------------

/"Coffee? I could quit anytime, just not today"
http://seelifedifferently.blogspot.com/