Amit Chawla DotNet: All and Sundry

 

I have been around in the sysdev scene for a fair bit. However, I have been able to very skillfully steer clear of this beast: JavaScript.

I could take my fair share of middle-tier, cross-platform integration, design patterns, and anything OO in just about any programming environment. However, ask me to write more than a couple of lines of JavaScript and I would cringe and find my way around it. 

Once Bitten, Twice Shy

Maybe because I’ve  been stuck in the late 90s spaghetti-code syndrome. When anyone who could ’spell’ ASP or JSP would most certainly be hired by a blue-chip company in the silicon valley. Anybody who could plagiarize a ‘business-plan’ would get venture capitalists knocking on their door. Cab-drivers [read common man] would ‘advise’ you to buy CISCO or Oracle shares.

We all know the result: Billions of lines of JavaScript code mish-mashed with the server-side technologies. So brittle were these application architectures that a mouse click in the wrong direction could bring them crashing down.

I was so Wrong

The problem was obviously in the abuse of the technology and not the technology itself. A couple of days ago I was faced with a JavaScript problem. Read on if you care…

The Problem

The  ASP.Net 2.0 validation framework contains a whole load of client-side and server-side code that helps with detecting validation errors and rendering error messages on the client.

Our sub-classed ValidationSummary control formats the messages differently. It has a custom header, different list layout and custom screen highlight functionality. Everything works well on the server-side, since we have the overridden Render(HtmlTextWriter). But, if the validators have EnableClientScript = “true”, the formatting breaks. Because, ASP.Net client-side code knows nothing about the funky formatting we have on the server-side.

The Solution

The ASP.Net 2.0 framework contains JavaScript based validation-framework library. This library is an embedded resource within the System.Web.dll. The function, ValidationSummaryOnSubmit(), within this library is run when a validation error occurs. The solution was to override this function with our own:

var original_Function;

original_Function = ValidationSummaryOnSubmit;

ValidationSummaryOnSubmit = ValidationSummaryOnSubmitEx;

function ValidationSummaryOnSubmitEx(validationGroup){

    //Do the HTML DOM stuff

    //Call the original function

    return original_Function(validationGroup);

}

I have since been able to exorcise my daemons.  

PS: I’d like to thank my colleague, Tim Duncan, who helped me put together the solution to the problem.

Filed under: Technology