Jeff's Blog

Or building a fondue set to make a grill cheese.

Encapsulation is a high art, when manifested; it is the crystalline marriage of tight self propellant function with duct tape like adaptable applicability and its full force of social inappropriateness. Patterns are fictional accounts of prismatic light dances that titillate the uninitiated to frothy heights in their pursuit. Application layers are despots that unscrupulously bind their subjects to untenable causeways. Or everything isn't as rosy as it is in the shiny bright pages of a text book.

Like many have before me, I recently found myself once again in the throes of a maddeningly self induce design corner. While working with a set of ASP.Net controls hosted in an Ajax UpdatePanel I found myself repeatedly battling the JavaScript timing of client side events and http gets on JavaScript resources. I had managed to convince myself that the user controls that I was created needed to be completely self contained and had to manage their own JavaScript resources. Normally this wouldn't be too much to ask of a control, but in the case I was struggling with, I was battling an UpdatePanel that hosted a PlaceHolderControl that could render 1 of 6 controls based on the data in the asynchronous request. Functionally this presented a problem in that the Ajax ScriptManager (client side) would processes script resources, either script blocks or includes, after it had updated the innerHTML property of the UpdatePanel. This allowed a user to interact with an HTML element that depended on scripts that might not be present at the time.

There are several strategies that can be used to mitigate this type of issue from simply in-lining scripts calls through the use of Literals or pushing the entirety of an event's JavaScript into the event attribute. Alternately defensive coding can be applied by using try catch blocks around any code that might call unavailable resources. I tried several variations of the above strategies, and the all worked, but still something just wasn't right about my approach.

After I had refactored my JavaScript and code behinds into a stable model that used defensive coding I thought it was a good time to compare what I had created with my initial coding requirements. I read over my list and saw the critical points of Performance, Durability, Recoverability, Encapsulation, etc. it seemed to me that I had done a fairly good job of meeting my development requirements, except that still something didn't seem right. Something seemed to be worming its way through the code digesting the solid structures into clay-soft muck. There were unsightly if blocks that existed only to enable the UserControls to guess at their hosting page's actual state. There were catch (e) { //do nothing }s strewn all about the JavaScript event attributes. It was just plain unsettling.

So I did what to me seemed the most logical thing at that point. I asked for opinions on my conclusions, and like a bolt from Olympus the light was shown upon my errant ways. These UserControls would not be re-used, they were strictly code "prettiness" encapsulations, and therefore I had no right to expect or force the controls to be standalone. So with one fell swoop dozens of unwieldy nested if blocks disappeared, and replaced by a two script include simple calls at the page level.

There are a few more posts I want to dredge up around this topic, but this is my stake in the ground. One of the "I think it should be" axioms of Software Development is that the best coding choices are most often made well before a single line of code is created. This is even more so in the GPS-Enabled Visual Studio development world. There's so much information available about where you are, where you've been and where it's possible for you to go, it's far too easy to forget about picking the best route.