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.
