I’m super excited to announce
the July 2013 release of
the Ajax Control Toolkit. You can download
the new version of
the Ajax Control Toolkit from CodePlex (http://ajaxControlToolkit.CodePlex.com) or install
the Ajax Control Toolkit from NuGet:
With this release, we have completely rewritten
the way
the Ajax Control Toolkit combines, minifies, gzips, and caches JavaScript files.
The goal of this release was to improve
the performance of
the Ajax Control Toolkit and make it easier to create custom Ajax Control Toolkit
controls.
Improving Ajax Control Toolkit Performance
Previous releases of
the Ajax Control Toolkit optimized performance for a single page but not multiple pages. When you visited each page in an app,
the Ajax Control Toolkit would combine all of
the JavaScript files required by
the controls in
the page into a new JavaScript file. So, even if every page in your app used
the exact same
controls, visitors would need to download a new combined Ajax Control Toolkit JavaScript file for each page visited.
Downloading new scripts for each page that you visit does not lead to good performance. In general, you want to make as few requests for JavaScript files as possible and take maximum advantage of caching.
For most apps, you would get much better performance if you could specify all of
the Ajax Control Toolkit
controls that you need for your entire app and create a single JavaScript file which could be used across your entire app. What a great idea!
Introducing Control Bundles
With this release of
the Ajax Control Toolkit, we introduce
the concept of Control Bundles. You define a Control Bundle to indicate
the set of Ajax Control Toolkit
controls that you want to use in your app.
You define Control Bundles in a file located in
the root of your application named AjaxControlToolkit.config. For example,
the following AjaxControlToolkit.config file defines two Control Bundles:
<ajaxControlToolkit>
<controlBundles>
<controlBundle>
<control name="CalendarExtender" />
<control name="ComboBox" />
</controlBundle>
<controlBundle name="CalendarBundle">
<control name="CalendarExtender"></control>
</controlBundle>
</controlBundles>
</ajaxControlToolkit>
The first Control Bundle in
the file above does not have a name. When a Control Bundle does not have a name then it becomes
the default Control Bundle for your entire application.
The default Control Bundle is used by
the ToolkitScriptManager by default. For example,
the default Control Bundle is used when you declare
the ToolkitScriptManager like this:
<ajaxToolkit:ToolkitScriptManager runat=”server” />
The default Control Bundle defined in
the file above includes all of
the scripts required for
the CalendarExtender and ComboBox
controls. All of
the scripts required for both of these
controls are combined, minified, gzipped, and cached automatically.
The AjaxControlToolkit.config file above also defines a second Control Bundle with
the name CalendarBundle. Here’s how you would use
the CalendarBundle with
the ToolkitScriptManager:
<ajaxToolkit:ToolkitScriptManager runat="server">
<ControlBundles>
<ajaxToolkit:ControlBundle Name="CalendarBundle" />
</ControlBundles>
</ajaxToolkit:ToolkitScriptManager>
In this case, only
the JavaScript files required by
the CalendarExtender control, and not
the ComboBox, would be downloaded because
the CalendarBundle lists only
the CalendarExtender control. You can use multiple named control bundles with
the ToolkitScriptManager and you will get all of
the scripts from both bundles.
Support for ControlBundles is a new feature of
the ToolkitScriptManager that we introduced with this release. We extended
the ToolkitScriptManager to support
the Control Bundles that you can define in
the AjaxControlToolkit.config file.
Let me be explicit about
the rules for Control Bundles:
1. If you do not create an AjaxControlToolkit.config file then
the ToolkitScriptManager will download all of
the JavaScript files required for all of
the controls in
the Ajax Control Toolkit. This is
the easy but low performance option.
2. If you create an AjaxControlToolkit.config file and create a ControlBundle without a name then
the ToolkitScriptManager uses that Control Bundle by default. For example, if you plan to use only
the CalendarExtender and ComboBox
controls in your application then you should create a default bundle that lists only these two
controls.
3. If you create an AjaxControlToolkit.config file and create one or more named Control Bundles then you can use these named Control Bundles with
the ToolkitScriptManager. For example, you might want to use different subsets of
the Ajax Control Toolkit
controls in different sections of your app.
I should also mention that you can use
the AjaxControlToolkit.config file with custom Ajax Control Toolkit
controls – new
controls that you write. For example, here is how you would register a set of custom
controls from an assembly named MyAssembly:
<ajaxControlToolkit>
<controlBundles>
<controlBundle name="CustomBundle">
<control name="MyAssembly.MyControl1" assembly="MyAssembly" />
<control name="MyAssembly.MyControl2" assembly="MyAssembly" />
</controlBundle>
</ajaxControlToolkit>
What about ASP.NET Bundling and Minification?
The idea of Control Bundles is similar to
the idea of Script Bundles used in ASP.NET Bundling and Minification. You might be wondering why we didn’t simply use Script Bundles with
the Ajax Control Toolkit. There were several reasons.
First, ASP.NET Bundling does not work with scripts embedded in an assembly. Because all of
the scripts used by
the Ajax Control Toolkit are embedded in
the AjaxControlToolkit.dll assembly, ASP.NET Bundling was not an option.
Second, Web Forms developers typically think at
the level of
controls and not at
the level of individual scripts. We believe that it makes more sense for a Web Forms developer to specify
the controls that they need in an app (CalendarExtender, ToggleButton) instead of
the individual scripts that they need in an app (the 15 or so scripts required by
the CalenderExtender).
Finally, ASP.NET Bundling does not work with older versions of ASP.NET.
The Ajax Control Toolkit needs to support ASP.NET 3.5, ASP.NET 4.0, and ASP.NET 4.5. Therefore, using ASP.NET Bundling was not an option.
There is nothing wrong with using Control Bundles and Script Bundles side-by-side.
The ASP.NET 4.0 and 4.5 ToolkitScriptManager supports both approaches to bundling scripts.
Using
the AjaxControlToolkit.CombineScriptsHandler
Browsers cache JavaScript files by URL. For example, if you request
the exact same JavaScript file from two different URLs then
the exact same JavaScript file must be downloaded twice. However, if you request
the same JavaScript file from
the same URL more than once then it only needs to be downloaded once.
With this release of
the Ajax Control Toolkit, we have introduced a new HTTP Handler named
the AjaxControlToolkit.CombineScriptsHandler. If you register this handler in your web.config file then
the Ajax Control Toolkit can cache your JavaScript files for up to one year in
the future automatically.
You should register
the handler in two places in your web.config file: in
the <httpHandlers> section and
the <system.webServer> section (don’t forget to register
the handler for
the AjaxFileUpload while you are there!).
<httpHandlers>
<add verb="*" path="AjaxFileUploadHandler.axd"
type="AjaxControlToolkit.AjaxFileUploadHandler, AjaxControlToolkit" />
<add verb="*" path="CombineScriptsHandler.axd"
type="AjaxControlToolkit.CombineScriptsHandler, AjaxControlToolkit" />
</httpHandlers>
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<handlers>
<add name="AjaxFileUploadHandler" verb="*" path="AjaxFileUploadHandler.axd"
type="AjaxControlToolkit.AjaxFileUploadHandler, AjaxControlToolkit" />
<add name="CombineScriptsHandler" verb="*" path="CombineScriptsHandler.axd"
type="AjaxControlToolkit.CombineScriptsHandler, AjaxControlToolkit" />
</handlers>
<system.webServer>
The handler is only used in release mode and not in debug mode. You can enable release mode in your web.config file like this:
<compilation debug=”false”>
You also can override
the web.config setting with
the ToolkitScriptManager like this:
<act:ToolkitScriptManager ScriptMode=”Release” runat=”server”/>
In release mode, scripts are combined, minified, gzipped, and cached with a far future cache header automatically.
When
the handler is not registered, scripts are requested from
the page that contains
the ToolkitScriptManager:
When
the handler is registered in
the web.config file, scripts are requested from
the handler:
If you want
the best performance, always register
the handler. That way,
the Ajax Control Toolkit can cache
the bundled scripts across page requests with a far future cache header. If you don’t register
the handler then a new JavaScript file must be downloaded whenever you travel to a new page.
Dynamic Bundling and Minification
Previous releases of
the Ajax Control Toolkit used a Visual Studio build task to minify
the JavaScript files used by
the Ajax Control Toolkit
controls.
The disadvantage of this approach to minification is that it made it difficult to create custom Ajax Control Toolkit
controls.
Starting with this release of
the Ajax Control Toolkit, we support dynamic minification.
The JavaScript files in
the Ajax Control Toolkit are minified at runtime instead of at build time.
Scripts are minified only when in release mode. You can specify release mode with
the web.config file or with
the ToolkitScriptManager ScriptMode property.
Because of this change,
the Ajax Control Toolkit now depends on
the Ajax Minifier. You must include a reference to AjaxMin.dll in your Visual Studio project or you cannot take advantage of runtime minification. If you install
the Ajax Control Toolkit from NuGet then AjaxMin.dll is added to your project as a NuGet dependency automatically. If you download
the Ajax Control Toolkit from CodePlex then
the AjaxMin.dll is included in
the download.
This change means that you no longer need to do anything special to create a custom Ajax Control Toolkit. As an open source project, we hope more people will contribute to
the Ajax Control Toolkit (Yes, I am looking at you.) We have been working hard on making it much easier to create new custom
controls. More on this subject with
the next release of
the Ajax Control Toolkit.
A Single Visual Studio Solution
We also made substantial changes to
the Visual Studio solution and projects used by
the Ajax Control Toolkit with this release. This change will matter to you only if you need to work directly with
the Ajax Control Toolkit source code.
In previous releases of
the Ajax Control Toolkit, we maintained separate solution and project files for ASP.NET 3.5, ASP.NET 4.0, and ASP.NET 4.5. Starting with this release, we now support a single Visual Studio 2012 solution that takes advantage of multi-targeting to build ASP.NET 3.5, ASP.NET 4.0, and ASP.NET 4.5 versions of
the toolkit.
This change means that you need Visual Studio 2012 to open
the Ajax Control Toolkit project downloaded from CodePlex. For details on how we setup multi-targeting, please see Budi Adiono’s blog post:
http://www.budiadiono.com/2013/07/25/visual-studio-2012-multi-targeting-framework-project/
Summary
You can take advantage of this release of
the Ajax Control Toolkit to significantly improve
the performance of your website. You need to do two things: 1) You need to create an AjaxControlToolkit.config file which lists
the controls used in your app and 2) You need to register
the AjaxControlToolkit.CombineScriptsHandler in
the web.config file.
We made substantial changes to
the Ajax Control Toolkit with this release. We think these changes will result in much better performance for multipage apps and make
the process of building custom
controls much easier. As always, we look forward to hearing your feedback.
