Viewing Automatic Scripts

Lest you think that avoiding scripts in your own code in any way frees the output of your application of them, it's important to consider what ASP.NET does for you in the background. Many activities that you request ASP.NET to perform for your application result in automatic script generation. In fact, often you'll find that adding a simple control to your Web page generates a script automatically.

Let's begin with a simple, but common, example. Place a CheckBox control on a Webform, followed by a TextBox control. Set the CheckBox control's AutoPostBack property to True. Set the TextBox control's Visible property to False. Add an event handler for the CheckBox1 CheckChanged() event.

Now add this simple statement to the event handler:

TextBox1.Visible = True

Developers often use this kind of code to simplify the user interface. A control remains hidden until the user explicitly needs to interact with it. In fact, some Web sites use this technique to implement menus; the technique is more common than you think.

So far, you haven't added a single line of script to this example... or have you? Start the example using Internet Explorer as your browser. Right click the browser window and choose View Source from the context menu. A copy of Notepad will open (unless you changed the defaults) and you'll see the actual source generated by ASP.NET. Figure 1 shows the unexpected results. Not only does the output contain a number of unexpected hidden controls, it also contains a script that you hadn't anticipated.

Figure 1: ASP.NET often generates scripts behind the scenes for tasks you thought the server handled.

You'll notice that this script is attached to CheckBox1 as the result of implementing the AutoPostBack feature. However, you'll find that ASP.NET generates scripts for a number of controls without changing anything. For example, all of the validator controls rely on scripts to perform their work.

The automatically generated scripts rely on an assortment of hidden fields, as shown in the figure. These hidden fields can greatly increase the size of the Web page and therefore, negatively affect performance. In short, your simple Web page might not be as simple or as script-free as you thought.

Master pages complicate this scenario. Even in this simple instance, using a master page can make it a lot harder to understand the script. Figure 2 shows the same Web page setup, but one created using a master page. Notice that name mangling makes it a lot harder to understand the script. You might not even know where ASP.NET generates the script, much less what task it performs.

Remember, this is a very simple scenario. Imagine trying to debug the complex Web pages that most real Web sites use, when a good portion of the scripts are generated automatically!

Figure 2: Adding a master page complicates matters by mangling the control name and making the script generally more complex.

Fortunately, you don't have to suffer through the negative aspects of automatic script generation by following a few simple rules. First, test potential script scenarios using simple cases as we have done here. If you intend to use this technique, see how it works by creating a simple scenario first, studying how the script works using the actual ASP.NET output to the browser, and then making notes for the more complex real world page. Second, reduce automation to what you actually need.

For example, if you don't rely on themes for your Web site, set the EnableTheming property to False for each control. Likewise, unless you actually use the view state information, set the EnableViewState property to False for each of the controls. When working with a master page, make sure you also check the ContentPlaceHolder control settings.