There are a few ways of doing so – you could have an asynchronous call return an HTML fragment, for instance (done that). You could also embed placeholders in hidden HTML fragments on a page, and use a combination of jQuery’s clone/replace/append methods to push object data into them (done that too). However, there’s an even better technique available now, as a first-class citizen in the jQuery library – the .tmpl templating API.

jQuery templating is a feature that’s currently in beta (though it is distributed with jQuery as of version 1.4.3), and is based upon an existing templating plugin. I’ve had the pleasure of using the jQuery templating API for a bit of time now, and I admit that it is by far the easiest, most robust templating solution I’ve found. There are template controls for repeaters ({{each}}), conditional statements ({{if}} and {{else}}), templated HTML fragments ({{html}}), and wrapping ({{wrap}}). That’s a lot of functionality out of the box!

By far my favorite part of html templating, however, is the <script type=’text/x-jquery-tmpl’></script> tagging that you can wrap around your template fragments. One thing I’ve disliked with templating is that you have to embed potentially malformed HTML into your page – for instance, you might end up having to template id attributes. Malformed html is not the worst thing in the world, especially in hidden fields, but it certainly doesn’t help with search engine rankings and such. Having a way of clearly saying “I’m a template fragment” is a great thing, both for search engines and general maintainability.

If you haven’t gotten a chance to take a look at jQuery templating, now is certainly a great time to do so. It comes for free with jQuery, and it’s a fast, easy, and robust solution for templating needs.

There is a solution, of course – just like almost every part of jQuery, the Sizzle selector engine is extensible. That’s right – you can implement your own selectors that you can then use just like native selectors (big props to Ben Nadel for demonstrating this technique). One of my first needs in this realm was to create a ‘between’ selector – give me all the elements ‘between’ selectors for element A and element B. Here’s an example of what we want the syntax to look like:

var rowsBetween = $('tr:between(tr:contains(Start), tr:contains(End))');

Given the selector above, we would expect it to return the following table rows:

In order to implement this selector, we’re going to make a few assumptions in order to get it to work. First, we’re going to assume that both the inside selectors resolve to a single element (actually, they can resolve to any number of elements, we will just use only the first match). Next, we are going to assume that the first element actually occurs before the last element. These assumptions obviously make for a buggy implementation of a real selector, but they are perfectly acceptable for a user-driven project.
So, down to it. The first thing we are going to do is setup the jQuery selector engine extension method:

$.expr[':'].between = function(
    objNode,
    intStackIndex,
    arrProperties,
    arrNodeStack)
{
	// Placeholder logic...
	return false;
};

Ben Nadel has an excellent writeup on the selector engine interface in his article http://www.bennadel.com/blog/1457-How-To-Build-A-Custom-jQuery-Selector.htm, so no need to cover it again. Now, our next task is to write the guts of our selector. Here’s the algorithm we are going to be implementing:

1. Split the arguments by ‘,’ (comma), so that we have the start and end selectors.
2. Find the start and end elements that correspond to the start and end selectors.
3. Is the element we are currently testing between the start and end elements?
   1. Yes -> return true
   2. No -> return false

This is a relatively easy algorithm to implement. First, let’s do the chopping:

    var args = arrProperties[3].split(",");
    var startSelector = args[0];
    var endSelector = args[1];

Now that we have the ‘between’ selector values, let’s get the corresponding elements from the element collection.

 var startIndex = -1;
    var endIndex = -1;

    // Find the start and end indexes.
    for (var index = 0; index < arrNodeStack.length; index++)
    {
        if ($(arrNodeStack[index]).is(startSelector) && startIndex < 0)
            startIndex = index;
        else if ($(arrNodeStack[index]).is(endSelector) && endIndex < 0)
            endIndex = index;
    }

$(arrNodeStack[index]) gives us the element that we are currently iterating over. In order to see if it matches our start/end selector, we use the jQuery is() method. We have a little handling here to keep from overwriting our values if we’ve already found a match, but it’s all pretty self-explanatory.

Our last task is to check to see if our selected element is between the start and end elements, and return the appropriate value. That again is pretty straightforward:

    if (startIndex >= 0 &&
        endIndex > 0 &&
        intStackIndex > startIndex &&
        intStackIndex < endIndex)
        return true;
    else
        return false;

Putting this all together, we get the following:

$.expr[':'].between = function(
    objNode,
    intStackIndex,
    arrProperties,
    arrNodeStack)
{
    var args = arrProperties[3].split(",");
    var startSelector = args[0];
    var endSelector = args[1];

    var startIndex = -1;
    var endIndex = -1;

    // Find the start and end indexes.
    for (var index = 0; index < arrNodeStack.length; index++)
    {
        if ($(arrNodeStack[index]).is(startSelector) && startIndex < 0)
            startIndex = index;
        else if ($(arrNodeStack[index]).is(endSelector) && endIndex < 0)
            endIndex = index;
    }

    if (startIndex >= 0 &&
        endIndex > 0 &&
        intStackIndex > startIndex &&
        intStackIndex < endIndex)
        return true;
    else
        return false;
};

That’s it! We’ve now got the ability to use the ‘between’ selector just like any other jQuery selector. Pretty simple, no? From not knowing a thing about selector engine extension to a finished product, this was only a few hours of work (mostly research, too). If you’re looking for an opportunity to try implementing a custom selector, try that ‘previous adjacent’ selector I talked about in the opening paragraph – it should be pretty easy to implement.

There’s a new set of jQuery API documentation, with a new look and some other enhancements. One thing I’m a big fan of is the ability to see when a particular function was added to jQuery – it’s very easy to hone in on the new stuff that way. One thing I feel is still missing is the abilityto jump directly to the function implementation in the library, like how the Google Closure API documentation is setup.

Interestingly, the last day of the 14-days-of-jQuery-1.4 promotion will be the release of jQuery UI 1.8. jQuery UI 1.8 is looking to be a smaller release – a bunch of bugfixes and few somewhat underwhelming plugins, as well as support for jQuery 1.4. There are a ton of great jQuery UI widgets and enhancements that are in the proposal and development stages, but the pace of development has been very slow, which is disappointing. I’d very much like to see jQuery UI development kicked into high gear.

Overall, this is looking to be a great jQuery release. I’m impressed with the performance improvements (addClass is three times as fast now? amazing!), and the new functionality improves the experience dramatically. A lot of functionality that used to have to be gotten through plugins is now in the framework itself, which will be a boon to development. Check it out now!

Google just open sourced Closure, their robust JavaScript library. Closure is used in a variety of Google products, notably GMail and Google Docs. I had a chance to play with it for a few minutes, and I’m posting my first impressions.

Google Closure is a fairly complete JavaScript framework. In that sense, it duplicates a lot of the functionality of existing JavaScript libraries, such as jQuery and YUI. It contains behaviors, AJAX, event handling, selectors, UI components, and more. The syntax is fairly straightforward, but it’s not the same as other libraries, so there’s a learning curve in getting acquainted with it.

Closure has excellent dependency management through a robust loading mechanism. Basically, if you don’t reference a certain piece of the library, rest assured that it’s not going to load (and slow down your page as a result). In addition, it comes with the Closure Compiler, which will walk your JavaScript, determine what libraries you need, then aggregate and compress all the required files. Being able to deploy one file instead of many is a great way of speeding up your site.

One thing that irks me is that there only way to get Closure is through Subversion access to the trunk. If Google wants Closure to be adopted widely, they’re going to need to start offering discrete, packaged versions of it. Many developers (and novices) will be put off by the current distribution method otherwise.

The API is well documented, and has links to the actual code for each method (something that I’ve not really seen before in API documentation). The API itself is very robust, with a ton of methods and accessors on each object. I’m not sure I’m a big fan of the way things are laid out in the API, but I don’t have enough experience with it to say anything definitively here.

One doesn’t have to stretch the imagination to believe that Closure has amazing potential. This is, after all, what GMail is built from. I’m excited that it’s been open-sourced and I can’t wait to use it a bit more. Google has given a grand gift to the developer community with this release.

I think the new ‘live’ event handlers are going to be great. I can’t stress how much the ‘live’ method has helped my JavaScript development – it makes event binding much less of a chore when dynamically creating page content (especially for trivial things, like bindings for button hover behavior). One of the things I’ve disliked, though, is the change event of dropdowns isn’t able to be live captured, which has led me to use Live Query for those purposes. With 1.4, it can be done with jQuery alone.

It will certainly be interesting to see if the Lazy Load code is included, for on-the-fly .css and .js includes. By conditionally loading javascript and css, a lot of bandwidth could be conserved by choosing to defer file retrieval for little-used site features.

Some of the other cool new features will undoubtedly be radio classes and the offset get/set methods – I can see using those to save a few lines of code. I’m betting that there will also be some performance increases with 1.4, so I’m excited about the release, even if it’s release is still a few months off yet.

I’ve just released my latest plugin, the jQuery UI Image Carousel! The plugin is a standard-fare image carousel, and it’s also fully compatible with jQuery UI. It’s got a few options that make it fairly versatile – from a minimal look all the way to a collapsible version with a custom header.

The JavaScript itself wasn’t that daunting – version 1.0 clocks in at around 180 lines. Most of it is presentation management as well – making sure that the correct jQuery UI classes are applied to the markup, and so forth. In total, it was a bit of a longer exercise – there was a lot of work to insure compatibility with older versions of IE, for instance. I hope you enjoy, and if you use it, please take a sec to leave a comment with your page URL.

<a href="blah..." onclick="return DoAction();">Link</a>

...

function DoAction() { /*Do Something */ return false; };

However, there’s a better way, using the event.preventDefault() method. I had the need to use this recently, when I was fixing a trivial issue with the Filament Group jQuery UI buttons – my ‘a href’ styled buttons were still clickable when they were disabled. An easy solution to this problem is to capture the click and prevent the default action. I hooked this action to all disabled buttons, as such.

$(".ui-state-disabled").click(function(event) { event.preventDefault(); });

This code isn’t that robust – if you were to add or remove the ui-state-disabled class after page load (which I didn’t have to), you’d want to make sure to handle it appropriately. Either way, preventDefault() is definitely an elegant solution to disabling a click action.

In other development, I’ve been trying to learn how to implement iPhone style gesture controls via JavaScript. I’ve been seriously spinning my wheels on this – my demo is turning out to be a dud, of sorts. It’s frustrating (especially the testing, which I can only do on my iPhone currently), but hopefully it comes together sooner or later.