Sometimes I grow frustrated when trying to solve apparently simple things, that end up taking most of the day to come up with an answer. And if the answer is one that is bordering on a hack, I am even more distraught. This happened to me again while trying to optimize the latest version of the webcontrols, that will now use the Microsoft AJAX extensions framework. The optimization deals with allowing the control to persist its current structure. For example, when you have a tree that supports populate on demand, and you expand a node, causing a callback to occur, the new structure should be persisted. When a postback occurs, the tree should remember its structure (including what nodes are expanded). The code for this was already done. It was being called with each node expand, and each node selection. A more optimal way to handle this would be to simply call this persistence logic just before submitting the page. Simple, right?
Uh, no actually. If you simply place an event handler on the form's onsubmit, you will only get notified when a submit button is pressed. You will miss all other postbacks (like an autopostback from a dropdownlist). Knowing the MS AJAX framework has a nice object and event model I expected to find an event exposed. This search yielded no results, so I decided to have a look at what the Control Toolkit does. There are two controls that need this same notification: TextBoxWatermark and ConfirmButton. The solution offered there was not as good as I'd hoped. The way these controls handle getting the event notification is as follows
1) Register the WebForm_OnSubmit event on the server with the following code
ScriptManager.RegisterOnSubmitStatement(this,typeof(ConfirmButtonExtender),"ConfirmButtonExtenderOnSubmit","null;");
ScriptManager.RegisterOnSubmitStatement(this,typeof(TextBoxWatermarkExtender),"TextBoxWatermarkExtenderOnSubmit","null;");
2a) When the control initializes on the client, the logic looks for the js function name that the ASP.NET runtime registers on the client. Note that neither registration method invokes a specific function (null as the last parameter)
function WebForm_OnSubmit() {
//Note: other page logic may register additional functions here as well!
null;
return true;
}
2b) A check to verify that a previous onsubmit handler was not already registered. Note, this is done with a shared/static property (not on the instance).
if ((typeof(WebForm_OnSubmit) == 'function') && !AjaxControlToolkit.TextBoxWatermarkBehavior._originalWebForm_OnSubmit) {
3) Assign the previous onsubmit handler for the watermark shared/static property to the current onsubmit handler
AjaxControlToolkit.TextBoxWatermarkBehavior._originalWebForm_OnSubmit = WebForm_OnSubmit;
4) Assign a new function reference to the existing handler.
WebForm_OnSubmit = AjaxControlToolkit.TextBoxWatermarkBehavior.WebForm_OnSubmit;
5) The shared/static method that was reassigned to WebForm_OnSubmit will first invoke the original onsubmit method, if it returns successfully it will then loop through all components/extenders currently registered, and if it is of the same type as the current one, invoke that instance's onsubmit handler
AjaxControlToolkit.TextBoxWatermarkBehavior.WebForm_OnSubmit = function() {
var result = AjaxControlToolkit.TextBoxWatermarkBehavior._originalWebForm_OnSubmit();
if (result) {
var components = Sys.Application.getComponents();
for(var i = 0 ; i < components.length ; i++) {
var component = components[i];
if (AjaxControlToolkit.TextBoxWatermarkBehavior.isInstanceOfType(component)) {
component._onSubmit();
}
}
}
return result;
}
At first I did not think that this logic would work, as I felt that it would loose the onsubmit events of any other code that utilized the RegisterOnSubmitStatement. However, after further review, I now see that it should work fine, as it is kind of like a linked list approach.
Issues
The first of three issues I have with this is similar to my issue with how the toolkit makes assumptions about what ASP.NET generated javascript names will be, in the earlier case it was the assumption on the function named WebForm_DoCallback, in this case it is WebForm_OnSubmit. While I do not anticipate MS changing the names of these functions, it certainly is not a dependency I would willingly keep unless necessary, as it could break going forward.
The second issue is in how there is no global handler inside the toolkit for this logic. Rather it is up to each control to rewrite this somewhat clunky functionality.
The last issue lies in an additional dependency the ConfirmButton places on the TextBoxWatermark. Apparently, if a watermark and confirm button exist on the same page, the watermark's handler needs to execute first. Obviously, this has a major issue for anyone else wishing to implement similar logic, as the confirm button will need to be reworked for each of these controls.
Different Approach
Not willing to live with this set of shortcomings, I decided to look for other approaches. Unfortunately, I found none, so I decided to code my own. What I came up with is a new component called submitComponent, that lives in the dnn.controls client-side namespace. The following is how it works
1) The server-side logic needs to register the componentbr
RegisterSubmitComponent(Me.Page)
This in turn add the following to the WebForm_OnSubmit function generated to the client
function WebForm_OnSubmit() {
//Note: other page logic may register additional functions here as well!
dnn.controls.submitComp.onsubmit();
return true;
}
2) The client-side dnn.controls script will instantiate the dnn.controls._submitComponent component, inheriting from Sys.Component. Inheriting from Sys.Component gives our new class the event handler logic we are looking for (getHandler, addHandler, removeHandler).
3) The control's script will add a handler for onsubmit, by calling the submitComponent's add_handler method
this._onsubmitDelegate = Function.createDelegate(this, this._onsubmit);
dnn.controls.submitComp.add_handler(this._onsubmitDelegate);
This approach does not have issue 1 listed above, as it does not hardcode the WebForm_OnSubmit method into the client-script, rather it uses the ASP.NET functionality as intended by registering the script to execute onsubmit. The second issue is addressed as there is now a global component that can be used by each of my controls. The last issue is not addressed by my component since I have no such requirements. However, the component could easily add an additional parameter to the add_handler method to specify it must execute last.
I can't help but think that this logic is already implemented somewhere and I have missed it. If anyone out there knows how to better handle this scenario please post a comment./p>