DoSubmitAndLock()

Please note that I just checked in a very major change to 
FormControl.js' doSubmitAndLock() functionality. Description of changes 
follows:

csc_033005_1 -
The previous fix had problems in Moz/FF on Linus; Jake also raised some 
additional issues I was unaware of. At this point, here's the status of 
things.

Right now there are 3 ways to attach javascript logic to a form button:

a) adding it the to the form's onsubmit handler - this would effectively 
act as a global function called before form submission for any button 
that uses doSubmitAndLock; if you don't want this  universal 
functionality, then you simply wouldn't define the form onsubmit handler

b) adding in function calls on a per-button basis using 
BAction.addScriptFunction - this is a very easy way of invoking 
different javascript functions on a per-button basis (Jake added this a 
while back and I wasn't aware of it). A little bit more rudimentary than 
BScript, but definitely  easier to use. Each js function referenced may 
return a false to abort the submit process

c) adding in functionality using BScript - this offers added flexibility 
in that you can prepend, append, or replace whatever functionality is 
already on that element. Here's an example...

BAction baction = new BAction(new DoFoo());
baction.addChild(new BScript(BScript.ON_CLICK, "doThis();", 
BScript.PREPEND));
baction.addChild(new BScript(BScript.ON_CLICK, "doThat();", 
BScript.APPEND));

So this would invoke doThis(), then the scripting associated w/ the 
DoFoo action, then doThat(). BScript is probably the most robust, OO way 
of doing scripting, BUT its also the most complex,  so we don't want to 
force it on anyone.

We will continue to support all 3 of these methods in the forseeable future.

Now, in regard to the disableBackButton stuff...I spent a bunch of time 
yesterday talking to the original author and trying to figure out why it 
broke (because when it did work, it was pretty cool).  The bottom line 
is that it still works in IE (so I'm reluctant to remove it altogether), 
BUT, Firefox  and Mozilla have both been modified so that any time a 
form is submitted (even from an internal IFRAME),  the browser history 
is updated. This means that back button disabling CAN'T work there (and 
probably  never will). At this point, that's the only use for the 
ClientServerHTTPLib.js.

If you are not using setDisableBackButton(true), then none of your 
rendering logic will be going through ClientServerHTTPLib.js - 
everything will be happening via FormControl.js (which I consider a good 
thing). For this reason, I've deprecated BAction.setDisableBackButton() 
and getDisableBackButton(). I'll be happy to reverse this decision if 
someone wants to figure out how to get it working in Firefox.

Given all that, I've done the following:

a) reverted ClientServerHTTPLib.js and FormControl.js back to previous 
code base

b) updated ClientServerHTTPLib.js to the latest jsrs version (wasn't 
really necessary, but I had to do it anyway to test the disable back 
button stuff); it not supports additional browser types (but like I 
said  above, the disable back button stuff is not working there, and 
that was the whole point of this script  in the first place)

c) updated FormControl.js - I originally though I could just do the if 
(ok == undefined) ok = false;, but I realized that there were several 
considerations I hadn't thought about -

c.1) first, we really do need the onsubmit logic as the very first thing 
in the process, in order to make it "global" (now, I need to know if 
this is going to break anything for anyone - do you have a need to 
define an onsubmit handler at the form level where you want some of the 
buttons to use DoSubmitAndLock and yet -NOT- invoke that handler?)

c.2) second, I decided that a function returning 'false' explicitly 
indicates 'hey we're done', but it seems to make better sense to me that 
true or void should both be interpreted as 'ok to continue' -  an 
example would be if you wanted to embed an alert function for debugging 
purposes; sticking that into  your addScriptFunction() shouldn't 
effectively terminate the submit, but if we treat an undefined  value as 
false, it will.

c.3) this of course causes a problem with the cshl_SubmitAndReplace, 
since it doesn't return any value - so I added a new function to 
FormControl.js called $bmvc_submitted, which simply returns false;  then 
I modified HTMLActionRenderer to set the action like this: 
",bmvc_SubmitAndReplace,$bmvc_submitted" -  what this does is 
effectively call a function that returns false AFTER the cshl_submit, so 
that it never  drops down into the final block. Hacky, but it works 
quite well.

c.4) Finally, I also went and changed the public method signatures to 
bmvc_ (did this in both FormControl.js and ClientServerHTTPLib.js) and 
the private signatures to $bmvc_ (only did this in FormControl.js).  I 
did this to try and address some namespace concerns that Jake raised. 
I'm open to alternatives here.

Note that this WILL require you to search your code for hardcoded 
references to these script signatures (see "4. javascript signature 
changes" section in A_Changes_Barracuda_2.0.txt for details)


I'm still waiting for feedback from Jake on this, but I wanted to get 
this out there for others to review as well.

-- 

Christian

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

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