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.
