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 id="Form1" runat="server"> <asp:ScriptManager runat="server" ID="ScriptManager" EnablePartialRendering="true" ScriptPath="~/CommonScripts" > </asp:ScriptManager> </form>
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.
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.