No more hijacking of __doPostBack in Whidbey
Note: this entry has moved.
Intercepting form submissions
A few months back I was asked by a developer on my team about the best way to make sure a function was always called before form submission. This is a recurring problem among web developers. Listening for form.onsubmit (by using Page.RegisterOnSubmitStatement ) is just not enough because it won’t fire when the form is submitted programmatically as ASP.NET’s __doPostBack function does:
function __doPostBack(eventTarget, eventArgument) {
var theform;
// …
theform.__EVENTTARGET.value = eventTarget.split("$").join(":");
theform.__EVENTARGUMENT.value = eventArgument;
// this won’t cause the form.onsubmit event to fire
theform.submit();
}
This means that for any given page in which the __doPostBack function is present we need another way to intercept form submissions. So, I told the developer to hijack __doPostBack…
Hijacking __doPostBack
A common technique, as we can’t modify __doPostBack to make it call our custom function, is to just hijack it:
// save a reference to the original __doPostBack
var __oldDoPostBack = __doPostBack;
// replace __doPostBack with another function
__doPostBack = AlwaysFireBeforeFormSubmit;
The implementation for our AlwaysFireBeforeFormSubmit should look like:
function AlwaysFireBeforeFormSubmit (eventTarget, eventArgument) {
// do whatever pre-form submission
// chores you need here
// finally, let the original __doPostBack do its work
return __oldDoPostBack (eventTarget, eventArgument);
}
Multiple hijackings is (usually) a bad thing
Last week, pages on one of our web apps started breaking. What happened was that this developer passed my recommendation to another developer. They both were developing controls and they both were interested in getting a chance to run a function before form submission. Now… pages including both controls were breaking because of the two hijacking attempts.
How can the hijacking of __doPostBack be coordinated between different devs on the same team or better yet between any devs in the entire world? :-) Easy enough: the framework should support it.
Hijacking with first-class support from the framework
This is exactly what I’ve done for our custom framework. Basically I’ve told every dev on every team on the project to never, never, ever hijack _doPostBack by themselves. Instead they will simply call Page.RegisterOnSubmitStatement and the framework will make sure their function get always called before a form submission.
Our framework now includes its own hijacking of __doPostBack and it’s the only one allowed to do so. The “impostor” function makes sure form.onsubmit gets always called by checking for its existence and then calling it. Pretty much like Whidbey will do.
Whidbey modifies __doPostBack
The ASP.NET team heard the many voices that were raised during last years regarding this topic and so decided to add support for this in Whidbey. Good news is this hijacking won’t be necessary anymore (so you can discard the all the previous paragraphs…) because the __doPostBack function has been modified to explicitly call form.onsubmit, something like this:
function __doPostBack(eventTarget, eventArgument) {
var theform;
// note how form.onsubmit is being called explicity
if (theForm.onsubmit == null || theForm.onsubmit()) {
theForm.__EVENTTARGET.value = eventTarget;
theForm.__EVENTARGUMENT.value = eventArgument;
theForm.submit();
}
}