Customizing the Location of Scripts

You’ve seen how you can provide Release and Debug versions of JavaScript files on disk, and the ScriptManager will automatically reference the correct version. And you’ve seen how to embed scripts in a dll for easier servicing. ASP.NET AJAX also allows you to further customize script reference behavior.

Setting the Script Path

You may want to put the common scripts for nested applications in a single location to allow the browser to cache a single copy for multiple directories. Typically, ASP.NET AJAX returns relative path references for script, so the browser can end up caching multiple copies of a script for different directories or applications within the same domain. The ScriptManager’s ScriptPath property allows you to define a path to use in lieu of the normal discovery process. This allows you to put the scripts in a single location and have all references in the domain refer to that location.

At first, this may not seem like much, but when you consider that, even compressed, the amount of script to enable ASP.NET AJAX scenarios is more than 10K, allowing each user to get just one copy instead of one for each subdomain or nested application can really add up. The perceived performance for the user in eliminating excess calls can be significant.

The following code demonstrates setting the ScriptPath to a central location for greater caching. Of course, this will not bypass browser security restrictions regarding isolating domain references, but for nested directories, it can increase perceived performance significantly.

 <form  runat="server"> <asp:ScriptManager runat="server"  EnablePartialRendering="true" ScriptPath="~/CommonScripts" > </asp:ScriptManager> </form>

I didn’t say overall performance is better, but perceived performance can be improved. Here’s the explanation: There are two aspects to the user experience associated with loading script. The first is how long it takes to retrieve the script from the server. The browser is good about caching script, so I tend to discount this overhead. Once the browser has the script for an application, it doesn’t need to retrieve it for each subsequent request. The second aspect of performance is how long it takes to load and process the script. The ASP.NET team has done comparisons of the prototype and closure models for JavaScript development. The prototype model appears to yield the best overall performance across various browsers. Although the processing time can ultimately be the bottleneck in loading script, avoiding unnecessary script retrieval can help an application feel more responsive for the user.

Resolving Script References

In addition to setting a static location for scripts, you can provide a handler to determine the location of scripts to use at runtime. The ScriptManager has an event called ResolveScriptReference that will trigger for each script and allow you to customize the behavior. For many situations, using the ResolveScriptReference event may not be necessary, but when you find that something about a script needs to be modified without replacing the dll in which it resides, this event can be a lifesaver.

ScriptManager Proxy

All of the examples in this chapter have been free-standing pages. There hasn’t been a master page involved in the layout. But, of course, master pages are often the centerpiece of real-world site designs. To use ASP.NET partial rendering features, you need a ScriptManager control on the page, but there can be only one. So, if you have a Master page where there is a ScriptManager control, and you want to override or customize some settings in a content page, you cannot simply add another ScriptManager. Instead, ASP.NET provides the ScriptManagerProxy control.

The ScriptManagerProxy control allows a content page to interact with the primary ScriptManager control from the Master page and to set values unique to the content page being requested. The ScriptManagerProxy supports all of the same settings you have seen for the ScriptManager, except that it is used in a content page to reference the ScriptManager control that exists on the Master page. Using the proxy without a ScriptManager control to reference in the Master will result in an error.

Script Compression

One of the concerns about leveraging JavaScript in the browser more for AJAX scenarios is the increased volume of script being sent to the client. The ScriptManager compresses scripts so that the data sent from server to browser is smaller. In addition, the ASP.NET AJAX scripts are distinctly different in the release and debug versions. Besides just skipping the extra parameter validation and error information, the release version of the scripts employs a process for removing extraneous comments and unnecessary whitespace. Tabs, newlines, and extra spaces are removed to make the size of the script as small as possible before it is compressed and sent to the client. In fact, the scripts are analyzed to reduce variable names to single letters for internal use to minimize the overall script size.