The jQuery JavaScript library has been steadily getting more popular and with recent developments from
Microsoft, jQuery is also getting ever more exposure on
the ASP.NET platform including now directly from
Microsoft. jQuery is a light weight, 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 on www.jquery.com. For me jQuery has had a huge impact on how I develop Web applications and was probably
the main reason I went from dreading to do JavaScript development to actually looking forward to implementing client side JavaScript functionality. It has also had a profound impact on my JavaScript skill level for me 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 toward 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 which 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, databinding and localization. As it turns out
Microsoft has rebuilt most 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 V1.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 however. 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, mainly because early incarnations were squarely aimed at control/component developers rather than application developers. For all
the functionality that these controls 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 for
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 some cases, 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 standard mechanism set for jQuery developers: By submitting 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 databinder 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 from 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 a 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. 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 renderd as a template inside of
the document: <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>
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 about
the full set of markup expressions available in
the documentation.
To load up this data you can use code like
the following:
<script type="text/javascript">
//var Proxy = new ServiceProxy("../PageMethods/PageMethodsService.asmx/");
$(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>
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 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 tempalte 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 above shows off some of
the basics, but there’s much for 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 Handling
Currently 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 of 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 Output
Templates 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 Access
Unlike 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 global objects or
the data item passed in. This may or may not be a big deal depending on
the complexity of your template logic.
Error handling has been discussed quite a bit and it’s likely there will be some solution to that particualar 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.
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. Strike one.
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 a then an explicit mapping where name is an ID in
the document.
The converter is required to explicitly assign
the value to
the element. Strike two.
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. 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 very little in most scenarios. 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. If you have ideas on how you want this feature to be more useful get involved and post your recommendations.
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. I also find
the choice of creating a jQuery plug-in questionable – it seems a standalone object – albeit one that relies on
the jQuery library – would provide a more intuitive interface than
the current forcing of options onto a plug-in style interface. Out of
the three
Microsoft created components this is by far
the least useful and least polished implementation at this point.
jQuery Globalization
http://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 for 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" style="width: 500px;">
<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:
alert($.parseDate("25.10.2010"));
alert($.parseInt("12.222")); // de-DE uses . for thousands separators
As you can see culture specific options are taken into account when parsing.
The globalization plugin provides rich support for a variety of locales:
Get a list of all available cultures
Query cultures for culture items (like currency symbol, separators etc.)
Localized string names for all calendar related items (days of week, months)
Generated off of .NET’s supported locales
In short you get much of
the same functionality that you already might be using in .NET on
the server side.
The plugin includes a huge number of locales and an Globalization.all.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 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 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 has been 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 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!© Rick Strahl, West Wind Technologies, 2005-2010Posted in jQuery ASP.NET
