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
