I've been spending some time over the last couple of days working with jQuery and a few helper components. jQuery a week ago or so released version 1.2 and a few days later a new jQuery UI library which looks to be pretty cool for a number of reasons. If you haven't looked at jQuery before I encourage you to take a look at this lean and flexible library - it's a joy to work with on the client side and is fairly feature rich to do common things right out of the box with a tiny footprint.

The new UI library is interesting because as I looked over the feature set I realized that they have nailed every one of the component scenarios that I I also require plus a few more additional ones. The core features that I think any UI library should have:

• Draggables
• Droppables
• Dialog windows
• Shadow
• Calendar
• Accordion

Other than the latter two I actually have implemented the above in my own library but given a consistent 'mainstream' library I'd gladly replace it with something else. jQuery UI also includes a number of other interesting features like TableSorter, Tabs, Selectables and Resizables, plus an interesting Magnifier that's quite nice for image based selections.

Unfortunately it looks like the UI library is not anywhere near as solid as the core library. There are still a number of errors that pop up a number of rendering inconsistencies with various browser as well as a general sense of API inconsistency as some of the controls were merely pulled in from external plugins (for example the calendar plug-in) so there's not quite what you'd expect from a consistent UI library. Currently there's also support only for a single theme with a couple of other half finished themes available. Some of the controls are pretty heavy handed in their use of themes as well overriding your own CSS assignments so you'd have to explicitly override the theming that the UI library provides. For example, there's a very cool TableSorter component that you can point at any table and get client side column sorting, but it will take over the theming so your original formatting is lost. A few of the other controls like the Dialog control (very cool implementation!)  will just render in themed colors.

The UI library is a first release and these types of issues are to be expected, but I'm going to bet that once these first release issues get ironed out, it will be pretty popular.

There are already tons of other UI libraries out there some like Dojo and  EXT that are extremely slick but fairly complex and very bulky. I think one of the reasons jQuery, which is a relatively new library, has been so successful is because it's focused on the most common scenarios and has made them very easy to use and keeping focus on what's important resulting in a compact library and easy to use syntax. From what I've seen so far of the UI library that same mantra seems to continue with the UI library and that's why I think it will be a big hit.

jQuery and other library interactions

I've been using jQuery off and on for certain applications usually in combination with other libraries and especially in combination with wwScriptLibrary which is part of my wwHoverPanel component (and also of the Fox Web Connection). jQuery is nice because it has some options that allow it to play nice with other libraries that have overlap for the dreaded $() function. In my early JavaScript naivite I  decided to implement a $() in my library that mimicked most of what the Prototype library does and that decision haunts me to this day. Although my library can detect an existing mapping to the $() and use that implementation instead, this unfortunately doesn't work as is with jQuery because its selector syntax is different (and IMHO more logical since it uses CSS style syntax).

Luckily with a little bit of tweaking jQuery can be made to work just fine by using either the explicit jQuery (which is what th $() is mapped to) or using closure wrapping to re-configure the actual function itself.

jQuery itself no problemo - it can work fine in combination with my library.

One of the nicest aspects of jQuery though it's its vibrant plug-in community. There are hundreds of plug-ins available for it for many different tasks from simple feature enhancements to complex controls that provide client side component functionality. The community and the ease with which plug-ins can be created is what makes jQuery one of the more interesting and most popular libraries (if not the most popular) at this time.

Unfortunately most components and add-on libraries don't follow jQueries noConflict() rules the same way as the jQuery library itself does. What's really surprising and a bit disappointing though is that the jQuery UI library also doesn't follow its own .noConflict() rules. None of the components work if you use the jQuery.noConflict() since all of the libraries use the $ function without re-routing it to the full jQuery function. A few of the components do use closure wrapping, but even that breaks in most cases as these controls hook up control events that reference the $ function, which eventually map outside of the closure scope. Bummer. I would have expected at least jQuery's 'official' library to respect these settings.

So I've been thinking about how to be a better citizen in the jQuery world with my library and since I will at some point be more closely integrating with jQuery per se I've been thinking for some time how to best approach this. A while ago I added code inside of the library to replace all the $() calls explicitly with a different simple function call. So I now have $w (which is basically getElementById()) and $ww() which is new wwControl(). $() is still mapped but only if it's not already mapped. If another library overrides it that is OK too at least for the library internal code which won't break since it now uses w$().

function $w(ControlId)
{
    if (typeof(ControlId) == "object")
        return ControlId;

    var Ctl = document.getElementById(ControlId);
    if (Ctl == null)
        return null;

    return Ctl;
}





// *** Also map $()
if (typeof(window.$) != "function")
{ window.$ = function(ControlId) { return $w(ControlId); } }

function $ww(element) {
    return new wwControl(element);
}

With this code in place, both the script library and jQuery (and any other library that maps $) can co-exist as long as the script code against the wwScriptLibrary uses $w().

Eventually though I want to yank all of this anyway and just use jQuery as the primary accessor mechanism. jQuery's selector syntax is just so much more flexible than the simplistic mechanism used above.

Still my library still has functionality that is not easily available else where and more importantly it interfaces with server side controls. So the wwMethodCallback control that allows remote callbacks and has server side code that can parse and process ASP.NET (Page, Control or Handler code) in response which is something that is usually missing with use of any JavaScript only library. Similar story with the HoverPanel/DragPanel controls that wrappers up most of the common behavior features into one easy to use client and server model.

Live and learn <s>. I wish I could just glom on to an existing library and not have to worry about low level stuff like this, but the truth is I have not found a satisfactory solution to the things that I like to do in my AJAX applications. Most of my AJAX related apps are driven purely through client to server messaging (ie. JSON messages) and a handful of user interface features that involve pop up windowing and a few basic effects. It's not much but it's surprisingly hard to even find even that in a light weight environment. wwHoverPanel has been a boon for me in my work - simple and small and fast without requiring special configuration.

I hope the time will come when I don't have to maintain my own, but the day is certainly not here yet. In the meantime I'll keep plugging away at it - heck, if nothing else it's a fun excercise <s>.