One thing that I’ve come to appreciate in control development in ASP.NET that use JavaScript is
the ability to have more control over script and script include placement than ASP.NET provides natively. Specifically in ASP.NET you can use either
the ClientScriptManager or ScriptManager to embed scripts and script references into pages via code. This works reasonably well, but
the script references that get generated are generated into
the HTML body and there’s very little operational control for placement of scripts. If you have multiple controls or several of
the same control that need to place
the same scripts onto
the page it’s not difficult to end up with scripts that render in
the wrong order and stop working correctly. This is especially critical if you load script libraries with dependencies either via resources or even if you are rendering referenced to CDN resources. Natively ASP.NET provides a host of methods that help embedding scripts into
the page via either Page.ClientScript or
the ASP.NET ScriptManager control (both with slightly different syntax): RegisterClientScriptBlock Renders a script block at
the top of
the HTML body and should be used for embedding callable functions/classes. RegisterStartupScript Renders a script block just prior to
the </form> tag and should be used to for embedding code that should execute when
the page is first loaded. Not recommended – use jQuery.ready() or equivalent load time routines. RegisterClientScriptInclude Embeds a reference to a script from a url into
the page. RegisterClientScriptResource Embeds a reference to a Script from a resource file generating a long resource file string All 4 of these methods render their <script> tags into
the HTML body.
The script blocks give you a little bit of control by having a ‘top’ and ‘bottom’ of
the document location which gives you some flexibility over script placement and precedence. Script includes and resource url unfortunately do not even get that much control – references are simply rendered into
the page in
the order of declaration.
The ASP.NET ScriptManager control facilitates this task a little bit with
the abililty to specify scripts in code and
the ability to programmatically check what scripts have already been registered, but it doesn’t provide any more control over
the script rendering process itself. Further
the ScriptManager is a bear to deal with generically because generic code has to always check and see if it is actually present. Some time ago I posted a ClientScriptProxy class that helps with managing
the latter process of sending script references either to ClientScript or ScriptManager if it’s available. Since I last posted about this there have been a number of improvements in this API, one of which is
the ability to control placement of scripts and script includes in
the page which I think is rather important and a missing feature in
the ASP.NET native functionality. Handling ScriptRenderModes One of
the big enhancements that I’ve come to rely on is
the ability of
the various script rendering functions described above to support rendering in multiple locations: /// <summary>
/// Determines how scripts are included into
the page
/// </summary>
public enum ScriptRenderModes
{
/// <summary>
/// Inherits
the setting from
the control or from
the ClientScript.DefaultScriptRenderMode
/// </summary>
Inherit,
/// Renders
the script include at
the location of
the control
/// </summary>
Inline,
/// <summary>
/// Renders
the script include into
the bottom of
the header of
the page
/// </summary>
Header,
/// <summary>
/// Renders
the script include into
the top of
the header of
the page
/// </summary>
HeaderTop,
/// <summary>
/// Uses ClientScript or ScriptManager to embed
the script include to
/// provide standard ASP.NET style rendering in
the HTML body.
/// </summary>
Script,
/// <summary>
/// Renders script at
the bottom of
the page before
the last Page.Controls
/// literal control. Note this may result in unexpected behavior
/// if /body and /html are not
the last thing in
the markup page.
/// </summary>
BottomOfPage
}
This enum is then applied to
the various Register functions to allow more control over where scripts actually show up. Why is this useful? For me I often render scripts out of control resources and these scripts often include things like a JavaScript Library (jquery) and a few plug-ins.
The order in which these can be loaded is critical so that jQuery.js always loads before any plug-in for example.
Typically I end up with a general script layout like this:
Core Libraries- HeaderTop
Plug-ins: Header
ScriptBlocks: Header or Script depending on other dependencies
There’s also an option to render scripts and CSS at
the very bottom of
the page before
the last Page control on
the page which can be useful for speeding up page load when lots of scripts are loaded.
The API syntax of
the ClientScriptProxy methods is closely compatible with ScriptManager’s using static methods and control references to gain access to
the page and embedding scripts.
For example, to render some script into
the current page in
the header:
// Create script block in header
ClientScriptProxy.Current.RegisterClientScriptBlock(this, typeof(ControlResources),
"hello_function", "function helloWorld() { alert('hello'); }", true,
ScriptRenderModes.Header);
// Same again - shouldn't be rendered because it's
the same id
ClientScriptProxy.Current.RegisterClientScriptBlock(this, typeof(ControlResources),
"hello_function", "function helloWorld() { alert('hello'); }", true,
ScriptRenderModes.Header);
// Create a second script block in header
ClientScriptProxy.Current.RegisterClientScriptBlock(this, typeof(ControlResources),
"hello_function2", "function helloWorld2() { alert('hello2'); }", true,
ScriptRenderModes.Header);
// This just calls ClientScript and renders into bottom of document
ClientScriptProxy.Current.RegisterStartupScript(this,typeof(ControlResources),
"call_hello", "helloWorld();helloWorld2();", true);
which generates:
<html xmlns="http://www.w3.org/1999/xhtml" >
<head><title>
</title>
<script type="text/javascript">
function helloWorld() { alert('hello'); }
</script>
<script type="text/javascript">
function helloWorld2() { alert('hello2'); }
</script>
</head>
<body>
…
<script type="text/javascript">
//<![CDATA[
helloWorld();helloWorld2();//]]>
</script>
</form>
</body>
</html>
Note that
the scripts are generated into
the header rather than
the body except for
the last script block which is
the call to RegisterStartupScript. In general I wouldn’t recommend using RegisterStartupScript – ever. It’s a much better practice to use a script base load event to handle ‘startup’ code that should fire when
the page first loads. So instead of
the code above I’d actually recommend doing:
ClientScriptProxy.Current.RegisterClientScriptBlock(this, typeof(ControlResources),
"call_hello", "$().ready( function() { alert('hello2'); });", true,
ScriptRenderModes.Header);
assuming you’re using jQuery on
the page.
For script includes from a Url
the following demonstrates how to embed scripts into
the header. This example injects a jQuery and jQuery.UI script reference from
the Google CDN then checks each with a script block to ensure that it has loaded and if not loads it from a server local location:
// load jquery from CDN
ClientScriptProxy.Current.RegisterClientScriptInclude(this, typeof(ControlResources),
"http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js",
ScriptRenderModes.HeaderTop);
// check if jquery loaded - if it didn't we're not online
string scriptCheck =
@"if (typeof jQuery != 'object')
document.write(unescape(""%3Cscript src='{0}' type='text/javascript'%3E%3C/script%3E""));";
string jQueryUrl = ClientScriptProxy.Current.GetWebResourceUrl(this, typeof(ControlResources),
ControlResources.JQUERY_SCRIPT_RESOURCE);
ClientScriptProxy.Current.RegisterClientScriptBlock(this, typeof(ControlResources),
"jquery_register", string.Format(scriptCheck,jQueryUrl),true,
ScriptRenderModes.HeaderTop);
// Load jquery-ui from cdn
ClientScriptProxy.Current.RegisterClientScriptInclude(this, typeof(ControlResources),
"http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/jquery-ui.min.js",
ScriptRenderModes.Header);
// check if we need to load from local
string jQueryUiUrl = ResolveUrl("~/scripts/jquery-ui-custom.min.js");
ClientScriptProxy.Current.RegisterClientScriptBlock(this, typeof(ControlResources),
"jqueryui_register", string.Format(scriptCheck, jQueryUiUrl), true,
ScriptRenderModes.Header);
// Create script block in header
ClientScriptProxy.Current.RegisterClientScriptBlock(this, typeof(ControlResources),
"hello_function", "$().ready( function() { alert('hello'); });", true,
ScriptRenderModes.Header);
which in turn generates this HTML:
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js" type="text/javascript"></script>
<script type="text/javascript">
if (typeof jQuery != 'object')
document.write(unescape("%3Cscript src='/WestWindWebToolkitWeb/WebResource.axd?d=DIykvYhJ_oXCr-TA_dr35i4AayJoV1mgnQAQGPaZsoPM2LCdvoD3cIsRRitHKlKJfV5K_jQvylK7tsqO3lQIFw2&t=633979863959332352' type='text/javascript'%3E%3C/script%3E"));
</script>
<title>
</title>
<script src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/jquery-ui.min.js" type="text/javascript"></script>
<script type="text/javascript">
if (typeof jQuery != 'object')
document.write(unescape("%3Cscript src='/WestWindWebToolkitWeb/scripts/jquery-ui-custom.min.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
$().ready(function() { alert('hello'); });
</script>
</head>
<body>
…</body>
</html>
As you can see there’s a bit more control in this process as you can inject both script includes and script blocks into
the document at
the top or bottom of
the header, plus if necessary at
the usual body locations. This is quite useful especially if you create custom server controls that interoperate with script and have certain dependencies.
The above is a good example of a useful switchable routine where you can switch where scripts load from by default –
the above pulls from Google CDN but a configuration switch may automatically switch to pull from
the local development copies if your doing development for example.
How does it work?
As mentioned
the ClientScriptProxy object mimicks many of
the ScriptManager script related methods and so provides close API compatibility with it although it contains many additional overloads that enhance functionality. It does however work against ScriptManager if it’s available on
the page, or Page.ClientScript if it’s not so it provides a single unified frontend to script access. There are however many overloads of
the original SM methods like
the above to provide additional functionality.
The implementation of script header rendering is pretty straight forward – as long as a server header (ie. it has to have runat=”server” set) is available. Otherwise these routines fall back to using
the default document level insertions of ScriptManager/ClientScript. Given that there is a server header it’s relatively easy to generate
the script tags and code and append them to
the header either at
the top or bottom. I suspect Microsoft didn’t provide header rendering functionality precisely because a runat=”server” header is not required by ASP.NET so behavior would be slightly unpredictable. That’s not really a problem for a custom implementation however.
Here’s
the RegisterClientScriptBlock implementation that takes a ScriptRenderModes parameter to allow header rendering:
/// <summary>
/// Renders client script block with
the option of rendering
the script block in
///
the Html header
///
/// For this to work Header must be defined as runat="server"
/// </summary>
/// <param name="control">any control that instance typically page</param>
/// <param name="type">Type that identifies this rendering</param>
/// <param name="key">unique script block id</param>
/// <param name="script">The script code to render</param>
/// <param name="addScriptTags">Ignored for header rendering used for all other insertions</param>
/// <param name="renderMode">Where
the block is rendered</param>
public void RegisterClientScriptBlock(Control control, Type type, string key, string script, bool addScriptTags, ScriptRenderModes renderMode)
{
if (renderMode == ScriptRenderModes.Inherit)
renderMode = DefaultScriptRenderMode;
if (control.Page.Header == null ||
renderMode != ScriptRenderModes.HeaderTop &&
renderMode != ScriptRenderModes.Header &&
renderMode != ScriptRenderModes.BottomOfPage)
{
RegisterClientScriptBlock(control, type, key, script, addScriptTags);
return;
}
// No dupes - ref script include only once
const string identifier = "scriptblock_";
if (HttpContext.Current.Items.Contains(identifier + key))
return;
HttpContext.Current.Items.Add(identifier + key, string.Empty);
StringBuilder sb = new StringBuilder();
// Embed in header
sb.AppendLine("\r\n<script type=\"text/javascript\">");
sb.AppendLine(script);
sb.AppendLine("</script>");
int? index = HttpContext.Current.Items["__ScriptResourceIndex"] as int?;
if (index == null)
index = 0;
if (renderMode == ScriptRenderModes.HeaderTop)
{
control.Page.Header.Controls.AddAt(index.Value, new LiteralControl(sb.ToString()));
index++;
}
else if(renderMode == ScriptRenderModes.Header)
control.Page.Header.Controls.Add(new LiteralControl(sb.ToString()));
else if (renderMode == ScriptRenderModes.BottomOfPage)
control.Page.Controls.AddAt(control.Page.Controls.Count-1,new LiteralControl(sb.ToString()));
HttpContext.Current.Items["__ScriptResourceIndex"] = index;
}
Note that
the routine has to keep track of items inserted by id so that if
the same item is added again with
the same key it won’t generate two script entries. Additionally
the code has to keep track of how many insertions have been made at
the top of
the document so that entries are added in
the proper order.
The RegisterScriptInclude method is similar but there’s some additional logic in here to deal with script file references and ClientScriptProxy’s (optional) custom resource handler that provides script compression
/// <summary>
/// Registers a client script reference into
the page with
the option to specify
///
the script location in
the page
/// </summary>
/// <param name="control">Any control instance - typically page</param>
/// <param name="type">Type that acts as qualifier (uniqueness)</param>
/// <param name="url">the Url to
the script resource</param>
/// <param name="ScriptRenderModes">Determines where
the script is rendered</param>
public void RegisterClientScriptInclude(Control control, Type type, string url, ScriptRenderModes renderMode)
{
const string STR_ScriptResourceIndex = "__ScriptResourceIndex";
if (string.IsNullOrEmpty(url))
return;
if (renderMode == ScriptRenderModes.Inherit)
renderMode = DefaultScriptRenderMode;
// Extract just
the script filename
string fileId = null;
// Check resource IDs and try to match to mapped file resources
// Used to allow scripts not to be loaded more than once whether
// embedded manually (script tag) or via resources with ClientScriptProxy
if (url.Contains(".axd?r="))
{
string res = HttpUtility.UrlDecode( StringUtils.ExtractString(url, "?r=", "&", false, true) );
foreach (ScriptResourceAlias item in ScriptResourceAliases)
{
if (item.Resource == res)
{
fileId = item.Alias + ".js";
break;
}
}
if (fileId == null)
fileId = url.ToLower();
}
else
fileId = Path.GetFileName(url).ToLower();
// No dupes - ref script include only once
const string identifier = "script_";
if (HttpContext.Current.Items.Contains( identifier + fileId ) )
return;
HttpContext.Current.Items.Add(identifier + fileId, string.Empty);
// just use script manager or ClientScriptManager
if (control.Page.Header == null || renderMode == ScriptRenderModes.Script || renderMode == ScriptRenderModes.Inline)
{
RegisterClientScriptInclude(control, type,url, url);
return;
}
// Retrieve script index in header
int? index = HttpContext.Current.Items[STR_ScriptResourceIndex] as int?;
if (index == null)
index = 0;
StringBuilder sb = new StringBuilder(256);
url = WebUtils.ResolveUrl(url);
// Embed in header
sb.AppendLine("\r\n<script src=\"" + url + "\" type=\"text/javascript\"></script>");
if (renderMode == ScriptRenderModes.HeaderTop)
{
control.Page.Header.Controls.AddAt(index.Value, new LiteralControl(sb.ToString()));
index++;
}
else if (renderMode == ScriptRenderModes.Header)
control.Page.Header.Controls.Add(new LiteralControl(sb.ToString()));
else if (renderMode == ScriptRenderModes.BottomOfPage)
control.Page.Controls.AddAt(control.Page.Controls.Count-1, new LiteralControl(sb.ToString()));
HttpContext.Current.Items[STR_ScriptResourceIndex] = index;
}
There’s a little more code here that deals with cleaning up
the passed in Url and also some custom handling of script resources that run through
the ScriptCompressionModule – any script resources loaded in this fashion are automatically cached based on
the resource id. Raw urls extract just
the filename from
the URL and cache based on that. All of this to avoid doubling up of scripts if called multiple times by multiple instances of
the same control for example or several controls that all load
the same resources/includes.
Finally RegisterClientScriptResource utilizes
the previous method to wrap
the WebResourceUrl as well as some custom functionality for
the resource compression module:
/// <summary>
/// Returns a WebResource or ScriptResource URL for script resources that are to be
/// embedded as script includes.
/// </summary>
/// <param name="control">Any control</param>
/// <param name="type">A type in assembly where resources are located</param>
/// <param name="resourceName">Name of
the resource to load</param>
/// <param name="renderMode">Determines where in
the document
the link is rendered</param>
public void RegisterClientScriptResource(Control control, Type type,
string resourceName,
ScriptRenderModes renderMode)
{
string resourceUrl = GetClientScriptResourceUrl(control, type, resourceName);
RegisterClientScriptInclude(control, type, resourceUrl, renderMode);
}
/// <summary>
/// Works like GetWebResourceUrl but can be used with javascript resources
/// to allow using of resource compression (if
the module is loaded).
/// </summary>
/// <param name="control"></param>
/// <param name="type"></param>
/// <param name="resourceName"></param>
/// <returns></returns>
public string GetClientScriptResourceUrl(Control control, Type type, string resourceName)
{
#if IncludeScriptCompressionModuleSupport
// If wwScriptCompression Module through Web.config is loaded use it to compress
// script resources by using wcSC.axd Url
the module intercepts
if (ScriptCompressionModule.ScriptCompressionModuleActive)
{
string url = "~/wwSC.axd?r=" + HttpUtility.UrlEncode(resourceName);
if (type.Assembly != GetType().Assembly)
url += "&t=" + HttpUtility.UrlEncode(type.FullName);
return WebUtils.ResolveUrl(url);
}
#endif
return control.Page.ClientScript.GetWebResourceUrl(type, resourceName);
}
This code merely retrieves
the resource URL and then simply calls back to RegisterClientScriptInclude with
the URL to be embedded which means there’s nothing specific to deal with other than
the custom compression module logic which is nice and easy.
What else is there in ClientScriptProxy?
ClientscriptProxy also provides a few other useful services
beyond what I’ve already covered here:
Transparent ScriptManager and ClientScript calls
ClientScriptProxy includes a host of routines that help figure out whether a script manager is available or not and all functions in this class call
the appropriate object – ScriptManager or ClientScript – that is available in
the current page to ensure that scripts get embedded into pages properly. This is especially useful for control development where controls have no control over
the scripting environment in place on
the page.
RegisterCssLink and RegisterCssResource
Much like
the script embedding functions these two methods allow embedding of CSS links. CSS links are appended to
the header or to a form declared with runat=”server”.
LoadControlScript
Is a high level resource loading routine that can be used to easily switch between different script linking modes. It supports loading from a WebResource, a url or not loading anything at all. This is very useful if you build controls that deal with specification of resource urls/ids in a standard way.
Check out
the full Code
You can check out
the full code to
the ClientScriptProxyClass here:
ClientScriptProxy.cs
ClientScriptProxy
Documentation (class reference)
Note that
the ClientScriptProxy has a few dependencies in
the West Wind Web Toolkit of which it is part of. ControlResources holds a few standard constants and script resource links and
the ScriptCompressionModule which is referenced in a few of
the script inclusion methods.
There’s also another useful ScriptContainer companion control to
the ClientScriptProxy that allows scripts to be placed onto
the page’s markup including
the ability to specify
the script location and script minification options.
You can find all
the dependencies in
the West Wind Web Toolkit repository:
West Wind Web Toolkit Repository
West Wind Web Toolkit Home Page© Rick Strahl, West Wind Technologies, 2005-2010Posted in ASP.NET JavaScript
