The jQuery JavaScript library has steadily gained popularity and with recent developments from Microsoft, jQuery is now also getting ever more exposure on the ASP.NET platform, including now directly from Microsoft. jQuery is a lightweight, open source DOM manipulation library for JavaScript that has changed how many developers think about JavaScript. You can download it and find more information on jQuery at www.jquery.com.
For me, jQuery has a huge impact on how I develop Web applications and was probably the main reason I went from dreading JavaScript development to actually looking forward to implementing client-side JavaScript functionality. It has also had a profoundly positive impact on my JavaScript skills by seeing how the library accomplishes things (and often reviewing the terse but excellent source code). jQuery made an uncomfortable development platform (JavaScript + DOM) a joy to work on. Although jQuery is by no means the only JavaScript library out there, its ease of use, small size, huge community of plug-ins and pure usefulness has made it easily the most popular JavaScript library available today.
As a long time jQuery user, I’ve been excited to see the developments from Microsoft that are bringing jQuery to more ASP.NET developers and providing more integration with jQuery for ASP.NET’s core features rather than relying on the ASP.NET AJAX library.
Microsoft and jQuery - Making Friends
jQuery is an open source project but in the last couple of years, Microsoft has really thrown its weight behind supporting this open source library as a supported component on the Microsoft platform. When I say supported, I literally mean supported: Microsoft now offers actual tech support for jQuery as part of their Product Support Services (PSS) as jQuery integration has become part of several of the ASP.NET toolkits and ships in several of the default Web project templates in Visual Studio 2010. The ASP.NET MVC 3 framework (still in beta) also uses jQuery for a variety of client-side support features including client-side validation, and we can look forward to more integration of client-side functionality via jQuery in both MVC and WebForms in the future. In other words, jQuery is becoming an optional but included component of the ASP.NET platform.
PSS support means that support staff will answer jQuery-related support questions as part of any support incidents related to ASP.NET. This provides some piece of mind to some corporate development shops that require end-to-end support from Microsoft.
In addition to including jQuery and supporting it, Microsoft has also been getting involved in providing development resources for extending jQuery’s functionality via plug-ins. Microsoft’s last version of the Microsoft AJAX Library - which is the successor to the native ASP.NET AJAX Library - included some really cool functionality for client templates, data binding and localization. As it turns out, Microsoft has rebuilt some of that functionality using jQuery as the base API and provided jQuery plug-ins of these components. Very recently, these three plug-ins were submitted and have been approved for inclusion in the official jQuery plug-in repository and been taken over by the jQuery team for further improvements and maintenance.
Even more surprising: The jQuery Templates component has actually been approved for inclusion in the next major update of the jQuery core in jQuery version 1.5, which means it will become a native feature that doesn’t require additional script files to be loaded. Imagine this - an open source contribution from Microsoft that has been accepted into a major open source project for a core feature improvement.
Microsoft has come a long way indeed!
What the Microsoft Involvement with jQuery Means to You
For Microsoft, jQuery support is a strategic decision that affects their direction in client-side development, but nothing stopped you from using jQuery in your applications prior to Microsoft’s official backing and, in fact, a large chunk of developers did so readily prior to Microsoft’s announcement. Official support from Microsoft brings a few benefits to developers. jQuery support in Visual Studio 2010 means built-in support for jQuery IntelliSense, automatically added jQuery scripts in many projects types, and a common base for client-side functionality that actually uses what most developers are already using. If you have already been using jQuery and were worried about straying from the Microsoft line and their internal Microsoft AJAX Library - worry no more. With official support and the change in direction towards jQuery, Microsoft is now following along what most in the ASP.NET community had already been doing by using jQuery, which is likely the reason for Microsoft’s shift in direction in the first place.
ASP.NET AJAX and the Microsoft AJAX Library weren’t bad technology - there was tons of useful functionality buried in these libraries. However, these libraries never got off the ground, primarily because early incarnations were aimed at control/component developers rather than application developers. For all the functionality that the libraries provided for control developers, they lacked in useful and easily usable application developer functionality that was easily accessible in day-to-day client-side development. The result was that even though Microsoft shipped support for these tools in the box (in .NET 3.5 and 4.0), other than for the internal support in ASP.NET for things like the UpdatePanel and the ASP.NET AJAX Control Toolkit as well as some third-party vendors, the Microsoft client libraries were largely ignored by the developer community, opening the door for other client-side solutions. Microsoft seems to be acknowledging developer choice in this case: Many more developers were going down the jQuery path rather than using the Microsoft-built libraries and there seems to be little sense in continuing development of a technology that largely goes unused by the majority of developers. Kudos to Microsoft for recognizing this and gracefully changing directions.
Note that even though there will be no further development in the Microsoft client libraries, they will continue to be supported so if you’re using them in your applications, there’s no reason to start running for the exit in a panic and start re-writing everything with jQuery. Although that might be a reasonable choice in due time, jQuery and the Microsoft libraries work well side by side so that you can leave existing solutions untouched even as you enhance them with jQuery.
The Microsoft jQuery Plug-ins - Solid Core Features
One of the most interesting developments in Microsoft’s embracing of jQuery is that Microsoft has started contributing to jQuery via a standard mechanism set for jQuery developers: by submitting jQuery plug-ins. Microsoft took some of the nicest new features of the unpublished Microsoft AJAX Client Library and re-wrote these components for jQuery and then submitted them as plug-ins to the jQuery plug-in repository. Accepted plug-ins get taken over by the jQuery team and that’s exactly what happened with the three plug-ins submitted by Microsoft with the templating plug-in even getting slated to be published as part of the jQuery core in the next major release (1.5).
The following plug-ins are provided by Microsoft:
- jQuery Templates - a client-side template rendering engine
- jQuery Data Link - a client-side data binder that can synchronize changes without code
- jQuery Globalization - provides formatting and conversion features for dates and numbers
The first two are ports of functionality that was slated for the Microsoft Ajax Library while functionality for the globalization library provides functionality that was already found in the original ASP.NET AJAX library. To me, all three plug-ins address a pressing need in client-side applications and provide functionality I’ve previously used in other incarnations, but with more complete implementations. Let’s take a close look at these plug-ins.
jQuery Templates
http://api.jquery.com/category/plugins/templates/
Client-side templating is a key component for building rich JavaScript applications in the browser. Templating on the client lets you avoid manually creating markup by creating DOM nodes and injecting them individually into the document via code. Rather, you can create markup templates - similar to the way you create classic ASP server markup - and merge data into these templates to render HTML which you can then inject into the document or replace existing content with. Output from templates are rendered as a jQuery matched set and can then be easily inserted into the document as needed.
Templating is key to minimize client-side code and reduce repeated code for rendering logic. Instead, a single template can be used in many places for updating and adding content to existing pages. Further, if you build pure AJAX interfaces that rely entirely on client rendering of the initial page content, templates allow you to use a single markup template to handle all rendering of each specific HTML section/element.
I’ve used a number of different client rendering template engines with jQuery in the past including jTemplates (a PHP-style templating engine) and a modified version of John Resig’s MicroTemplating engine, which I built into my own set of libraries because it’s such a commonly used feature in my client-side applications.
jQuery templates adds a much richer templating model that allows for sub-templates and access to the data items. Like John Resig’s original Micro Template engine, the core basics of the templating engine create JavaScript code, which means that templates can include JavaScript code.
<script id="stockTemplate" type="text/x-jquery-tmpl">
<div id="divStockQuote" class="errordisplay"
style="width: 500px;">
<div class="label">Company:</div>
<div><b>${Company}(${Symbol})</b></div>
<div class="label">Last Price:</div>
<div>${LastPrice}</div>
<div class="label">Net Change:</div><div>
{{if NetChange > 0}}
<b style="color:green" >${NetChange}</b>
{{else}}
<b style="color:red" >${NetChange}</b>
{{/if}}
</div>
<div class="label">Last Update:</div>
<div>${LastQuoteTimeString}</div>
</div>
</script>
To give you a basic idea of how templates work, imagine I have an application that downloads a set of stock quotes based on a symbol list then displays them in the document. To do this, you can create an ‘item’ template that describes how each of the quotes is rendered as a template inside of the document:
<script type="text/javascript">
$(document).ready(function () {
$("#btnGetQuotes").click(GetQuotes);
});
function GetQuotes() {
var symbols = $("#txtSymbols").val().split(",");
$.ajax({
url: "../PageMethods/PageMethodsService.asmx/GetStockQuotes",
data: JSON.stringify({ symbols: symbols }), // parameter map
type: "POST", // data has to be POSTed
contentType: "application/json",
timeout: 10000,
dataType: "json",
success: function (result) {
var quotes = result.d;
var jEl = $("#stockTemplate").tmpl(quotes);
$("#quoteDisplay").empty().append(jEl);
},
error: function (xhr, status) {
alert(status + "\r\n" + xhr.responseText);
}
});
};
</script>
The ‘template’ is little more than HTML with some markup expressions inside of it that define the template language. Notice the embedded ${} expressions which reference data from the quote objects returned from an AJAX call on the server. You can embed any JavaScript or value expression in these template expressions. There are also a number of structural commands like {{if}} and {{each}} that provide for rudimentary logic inside of your templates as well as commands ({{tmpl}} and {{wrap}}) for nesting templates. You can find more information about the full set of markup expressions available in the documentation.
To load up this data you can use code like the following:
In this case, an ASMX AJAX service is called to retrieve the stock quotes. The service returns an array of quote objects. The result is returned as an object with the .d property (in Microsoft service style) that returns the actual array of quotes. The template is applied with:
var jEl = $("#stockTemplate").tmpl(quotes);
which selects the template script tag and uses the .tmpl() function to apply the data to it. The result is a jQuery matched set of elements that can then be appended to the quote display element in the page.
The template is merged against an array in this example. When the result is an array, the template is automatically applied to each array item. If you pass a single data item - like say a stock quote - the template works exactly the same way but is applied only once. Templates also have access to a $data item, which provides the current data item and information about the template that is currently executing. This makes it possible to keep context within the context of the template itself and also to pass context from a parent template to a child template which is very powerful.
Templates can be evaluated by using the template selector and calling the .tmpl() function on the jQuery matched set as shown above or you can use the static $.tmpl() function to provide a template as a string. This allows you to dynamically create templates in code or - more likely - to load templates from the server via AJAX calls. In short, there are options.
The example above shows off some of the basics, but there’s much more functionality available in the template engine. Check the documentation link for more information and links to additional examples. The plug-in download also comes with a number of examples that demonstrate functionality.
jQuery templates will become a native component in jQuery Core 1.5, so it’s definitely worthwhile checking out the engine today and get familiar with this interface. As much as I’m stoked about templating becoming part of the jQuery core because it’s such an integral part of many applications, there are also a couple shortcomings in the current incarnation:
- Lack of Error HandlingCurrently, if you embed an expression that is invalid it’s simply not rendered. There’s no error rendered into the template nor do the various template functions throw errors which leaves finding bugs as a runtime exercise. I would like some mechanism - optional if possible - to be able to get error info of what is failing in a template when it’s rendered.
- No String OutputTemplates are always rendered into a jQuery matched set and there’s no way that I can see to directly render to a string. String output can be useful for debugging as well as opening up templating for creating non-HTML string output.
- Limited JavaScript AccessUnlike John Resig’s original MicroTemplating Engine which was entirely based on JavaScript code generation, these templates are limited to a few structured commands that can “execute”. There’s no code execution inside of script code which means you’re limited to calling expressions available in objects that are in scope or the data item passed in.
Error handling has been discussed quite a bit and it’s likely there will be some solution to that particular issue by the time jQuery templates ship. The others are relatively minor issues but something to think about anyway.
jQuery Data Link
http://api.jquery.com/category/plugins/data-link/
jQuery Data Link provides the ability to do two-way data binding between input controls and an underlying object’s properties. The typical scenario is linking a textbox to a property of an object and have the object updated when the text in the textbox is changed and have the textbox change when the value in the object or the entire object changes. The plug-in also supports converter functions that can be applied to provide the conversion logic from string to some other value typically necessary for mapping things like textbox string input to say a number property and potentially applying additional formatting and calculations.
In theory this sounds great; however, in reality this plug-in has some serious usability issues at this point.
Using the plug-in you can do things like the following to bind data:
person = { firstName: "rick", lastName: "strahl"};
$(document).ready( function() {
// provide for two-way linking of inputs
$("form").link(person);
// bind to non-input elements explicitly
$("#objFirst").link(person, {
firstName: {
name: "objFirst",
convertBack: function (value, source, target) {
$(target).text(value);
}
}
});
$("#objLast").link(person, {
lastName: {
name: "objLast",
convertBack: function (value, source, target) {
$(target).text(value);
}
}
});
});
This code hooks up two-way linking between a couple of textboxes on the page and the person object. The first line in the .ready() handler provides mapping of object to form field with the same field names as properties on the object. Note that .link() does NOT bind items into the textboxes when you call .link() - changes are mapped only when values change and you move out of the field.
The two following commands allow manual binding of values to specific DOM elements which is effectively a one-way bind. You specify the object and then an explicit mapping where name is an ID in the document. The converter is required to explicitly assign the value to the element.
You can also detect changes to the underlying object and cause updates to the input elements bound. Unfortunately the syntax to do this is not very natural as you have to rely on the jQuery data object. The syntax to update an object’s properties and get change notification looks like this:
function updateFirstName() {
$(person).data("firstName", person.firstName +
" (code updated)");
}
This works fine in causing any linked fields to be updated. In the bindings above, both the firstName input field and objFirst DOM element gets updated. But the syntax requires you to use a jQuery .data() call for each property change to ensure that the changes are tracked properly. Really? Sure, you’re binding through multiple layers of abstraction now but how is that better than just manually assigning values? The code savings (if any) are going to be minimal.
As much as I would like to have a WPF/Silverlight/Observable-like binding mechanism in client script, this plug-in doesn’t help much towards that goal in its current incarnation. While you can bind values, the “binder” is too limited to be really useful. If initial values can’t be assigned from the mappings you’re going to end up duplicating work loading the data using some other mechanism. There’s no easy way to re-bind data with a different object altogether since updates trigger only through the data members. Finally, any non-input elements have to be bound via code that’s fairly verbose and frankly may be more voluminous than what you might write by hand for manual binding and unbinding.
Two-way binding can be very useful but it has to be easy and most importantly natural. If it’s more work to hook up a binding than writing a couple of lines to do binding/unbinding, this sort of thing helps nothing. In talking to some of the developers, the feature set for Data Link is not complete and they are still soliciting input for features and functionality.
As it stands, it looks to me like this component needs a lot of love to become useful. For this component to really provide value, bindings need to be able to be refreshed easily and work at the object level, not just the property level. It seems to me we would be much better served by a model binder object that can perform these binding/unbinding tasks in bulk rather than a tool where each link has to be mapped first. Out of the three components created by Microsoft this is by far the least useful and polished implementation at this point.
jQuery Globalization
http://www.github.com/jquery/jquery-global
Globalization in JavaScript applications often gets short shrift and part of the reason for this is that natively in JavaScript there’s little support for formatting and parsing of numbers and dates. There are a number of JavaScript libraries out there that provide some support for globalization, but most are limited to a particular portion of globalization. As .NET developers, we’re fairly spoiled by the richness of APIs provided in the framework and when dealing with client development, one really notices the lack of these features.
While you may not necessarily need to localize your application, the globalization plug-in also helps with some basic tasks for non-localized applications: Dealing with formatting and parsing of dates and time values. Dates in particular are problematic in JavaScript as there are no formatters whatsoever except the .toString() method, which outputs a verbose and next to useless long string. With the globalization plug-in you get a good chunk of the formatting and parsing functionality that the .NET framework provides on the server.
You can write code like the following example to format numbers and dates:
var date = new Date();
var output =
$.format(date, "MMM. dd, yy") + "\r\n" +
$.format(date, "d") + "\r\n" + // 10/25/2010
$.format(1222.32213, "N2") + "\r\n" +
$.format(1222.33, "c") + "\r\n";
alert(output);
This becomes even more useful if you combine it with templates which can also include any JavaScript expressions. Assuming the globalization plug-in is loaded, you can create template expressions that use the $.format function. Here’s the template I used earlier for the stock quote again with a couple of formats applied:
<script id="stockTemplate" type="text/x-jquery-tmpl">
<div id="divStockQuote" class="errordisplay">
<div class="label">Company:</div>
<div><b>${Company}(${Symbol})</b></div>
<div class="label">Last Price:</div>
<div>${$.format(LastPrice,"N2")}</div>
<div class="label">Net Change:</div><div>
{{if NetChange > 0}}
<b style="color:green" >${NetChange}</b>
{{else}}
<b style="color:red" >${NetChange}</b>
{{/if}}
</div>
<div class="label">Last Update:</div>
<div>${$.format(LastQuoteTime,"MMM dd, yyyy")}</div>
</div>
</script>
There are also parsing methods that can parse dates and numbers from strings into numbers easily. In the following example I’m parsing dates and numbers for the German locale:
$.preferCulture("de-DE");
alert($.parseDate("25.10.2010"));
alert($.parseInt("12.222")); // de-DE uses .
As you can see, culture-specific options are taken into account when parsing.
The globalization plug-in provides rich support for a variety of locales. You can:
- Get a list of all available cultures
- Query cultures for culture items (like currency symbol, separators etc.)
- Localize string names for all calendar-related items (days of week, months)
- Generated of .NET’s supported locales
In short, you get much of the functionality that you are already familiar with in .NET on the server side.
The plug-in includes a huge number of locales and a Globalization .ali .min .js file that contains the text defaults for each of these locales as well as small locale-specific script files that define each of the locale-specific settings. It’s highly recommended that you NOT use the huge globalization file that includes all locales, but rather add script references to only those languages you explicitly care about.
Overall this plug-in is a welcome helper. Even if you use it with a single locale (like en-US) and do no other localization, you’ll gain solid support for number and date formatting which is a vital feature of many applications.
Changes for Microsoft
It’s good to see Microsoft coming out of its shell and moving away from the “not-built-here” mentality that has been so pervasive in the past. It’s especially good to see it applied to jQuery - a technology that has stood in drastic contrast to Microsoft’s own internal JavaScript efforts in terms of design, usage model and popularity. It’s great to see that Microsoft is paying attention to what customers prefer to use and supporting the customer sentiment - even if it meant drastically changing course of policy and moving into a more open and sharing environment in the process. The additional jQuery support that Microsoft introduced in the last two years certainly has made lives easier for many developers on the ASP.NET platform.
It’s also nice to see Microsoft submitting proposals through the standard jQuery process of plug-ins and getting accepted for various very useful projects. Certainly the jQuery Templates plug-in is going to be very useful to many developers, especially since it will be baked into the jQuery core in jQuery 1.5. I hope we see more of this type of involvement from Microsoft in the future. Kudos!
