Introduction
ScriptManager is a special ASP.NET server control that should be placed on a page before you can use any of AJAX.NET enabled controls. The same rule is true for the AJAX Control Toolkit controls: they all require a ScriptManager on the page. While AJAX Control Toolkit controls work perfectly fine with the standard ASP.NET ScritpManager the Toolkit includes its own version of the ScriptManager called ToolkitScriptManager that inherits from ScriptManager and is meant to improve some of the ScriptManager's behaviors in particular how it renders out behavior JS scripts. Let's examine how using a ToolkitScriptManager changes a web page's appearance.
Experiment
As a testing example I have created a very simple page consisting of a single Accordion control from the AJAX Control Toolkit library.
<head runat="server">
<title>Untitled Page</title>
<style type="text/css">
.accHead { border:1px solid #445566;font-size:larger;background-color:#aaa;}
.accHeadSel { border:1px solid #445566;font-size:larger;background-color:#444;color:#fff;}
.accCont { border:1px solid #ccc;padding:5px;}
</style>
</head>
<body>
<form id="form1" runat="server">
<ajax:ToolkitScriptManager ID="tsm" runat="server"></ajax:ToolkitScriptManager>
<%-- <asp:ScriptManager ID="sm" runat="server"></asp:ScriptManager>--%>
<div>
<ajax:Accordion
ID="MyAccordion"
runat="Server"
SelectedIndex="0"
HeaderCssClass="accHead"
HeaderSelectedCssClass="accHeadSel"
ContentCssClass="accCont"
AutoSize="None"
FadeTransitions="true"
TransitionDuration="250"
FramesPerSecond="40"
RequireOpenedPane="false"
SuppressHeaderPostbacks="true">
<Panes>
<ajax:AccordionPane ID="AccordionPane1" runat="server"
HeaderCssClass="accHead"
ContentCssClass="accCont">
<Header>Pane Header 1</Header>
<Content>Content 1</Content>
</ajax:AccordionPane>
<ajax:AccordionPane ID="AccordionPane2" runat="server"
HeaderCssClass="accHead"
ContentCssClass="accCont">
<Header>Pane Header 2</Header>
<Content>Content 2</Content>
</ajax:AccordionPane>
<ajax:AccordionPane ID="AccordionPane3" runat="server"
HeaderCssClass="accHead"
ContentCssClass="accCont">
<Header>Pane Header 3</Header>
<Content>Content 3</Content>
</ajax:AccordionPane>
</Panes>
<HeaderTemplate>List of Panes</HeaderTemplate>
<ContentTemplate></ContentTemplate>
</ajax:Accordion>
</div>
</form>
</body>
You may have noticed that right after the form tag there are ScriptManager (SM) control and ToolkitScriptManager (TSM) control on the page but one of them is commented out. Next I run a page from VS 2008 two times: first using the SM and second using TSM, and compare the results.
HTML output and traffic
Let's compare the HTML output of two page versions. See a WinMerge screen shot below that shows the SM version in the left pane and the TSM version in the right pane.
First difference you see is that TSM adds its own hidden field on the page (top right pane) and the next and more important difference is that TSM renders one script reference on the page instead of the five ones that SM does.
Now if we examine the page's traffic with the FireBug we'll see how that changes the traffic: first graph refers to the page using the SM control and the second one when the TSM's at work.
Analyzing the graphs it's easy to see that the TSM does reduce a number of browser's round-trips by combining multiple script references into a single one. This advantage will become more attractive as more AJAX-enabled server controls will be placed on a web page that support script combining. However it is not necessarily true that it will always reduce the page loading time. As you can see when TSM returns a combined script to the page it takes some time to perform a work on the server. Correspondingly the amount of work and consequentially the response time directly depend on the number of scripts to combine (that is a number of AJAX server controls) and the size of the scripts to process (white spaces removal and compressing).
So there is no single recommendation that it's always preferable to use TSM instead of SM. In many cases SM version of a page may work faster then a TSM version of the page. Since it's not that difficult to alter a page for both cases I'd advise to test and compare both versions in your particular scenario before making a decision which one to choose.
Hi All,
ReplyDeleteI need one help from you. I am trying to set focus todifferent controls after my different PostBack events, butthis.ScriptManager1.SetFocus(myControlName.ClientID); is not working.
In my ASPX page I have RAD CONTROLS (RadComboBox and RadCalendar) and alsoI am using AjaxControlToolkit Controls (ToolkitScriptManager andModalPopupExtender) also.
In my page, RadComboBox is inUpdatePanel - ContentTemplate area and on its SelectedIndexChangedfunction I am trying to set focus to another Control using the abovecode:
this.ScriptManager1.SetFocus(myControlName.ClientID);
but this is not working... Do anyone know any solution for this?
Can I use ToolkitScriptManager for set focus?
Thanks...
Hi All,
ReplyDeleteI got solution for the above issue. I was trying to set focus using the code
this.ScriptManager1.SetFocus(myControlName.ClientID);
and I wrote this code in my SelectedIndexChanged Event Function. That time this code didn't work.
Now I changed this code to Page Load Function i.e.
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
this.ScriptManager1.SetFocus(myControlName.ClientID);
}
else
{
this.ScriptManager1.SetFocus(GetPostBackControl(this.Page).ClientID);
}
}
Here I am using a function GetPostBackControl() to identify the current postbacking control and I am setting focus to the same control. If you want to move focus to any other control, just use a Switch Statment.
public static System.Web.UI.Control GetPostBackControl(System.Web.UI.Page page)
{
Control control = null;
string ctrlname = page.Request.Params["__EVENTTARGET"];
if (ctrlname != null && ctrlname != String.Empty)
{
control = page.FindControl(ctrlname);
}
// if __EVENTTARGET is null, the control is a button type and we need to
// iterate over the form collection to find it
else
{
string ctrlStr = String.Empty;
Control c = null;
foreach (string ctl in page.Request.Form)
{
// handle ImageButton controls ...
if (ctl.EndsWith(".x") || ctl.EndsWith(".y"))
{
ctrlStr = ctl.Substring(0, ctl.Length - 2);
c = page.FindControl(ctrlStr);
}
else
{
c = page.FindControl(ctl);
}
if (c is System.Web.UI.WebControls.Button ||
c is System.Web.UI.WebControls.ImageButton)
{
control = c;
break;
}
}
}
return control;
}
Thank you,
Hello, I am modifying a web application that also uses ajaxToolkit:ToolkitScriptManager; specifically, I need to make some WebService methods (defined in separate .asmx files) accessible through javascript from the client.
ReplyDeleteThis, simply put, doesn't work; but if I replace the ToolkitScriptManager with the standard asp:ScriptManager, it works again.
So it would seem that the ToolkitScriptManager has the significant drawback of preventing association of WebServices to client script by normal means; can anyone confirm that? I could not find any documentation of this anywhere on the net.
Hello
ReplyDeleteFrom my practice I experienced a situation when using TSM increased page load performance. There was a single hint - set
LoadScriptsBeforeUI = false
While the ToolkitScriptManager control will combine the .axd files with JavaScript, it won't combine the .axd files with CSS. You need to use the CombineAndMinify package to combine and minify those files. It is at http://www.codeproject.com/KB/aspnet/CombineAndMinify.aspx
ReplyDeleteAFAIK, ToolkitScriptManager control was superseded by CompositeScript property of ScriptManager in .Net 3.5/4.: see http://www.asp.net/ajaxlibrary/Combining%20Client%20Scripts%20into%20a%20Composite%20Script.ashx
ReplyDeleteI have also had a weird experience were tabs do not display using SM, but do display using TSM after upgrading from 1.0.6 to 3.5.
ReplyDeleteI have a website with updatepanels and autorefresh partial postback feature. The browser used to crash in about 4 hours of refreshing with 20 seconds refresh interval due to hughe RAM usage up to 1.5GB. I almost tear my hair apart to finaly find out that it was caused by ScriptManager.RegisterStartupScript method. The only thing i had to do was changing it to AjaxControlToolkit.ToolkitScriptManager.RegisterStartupScript method.
ReplyDelete