-
Get a monthly update on best practices for delivering successful software.
I'm as geeked about jQuery's 1.3 release as the next developer. But I'm even more excited about the new API browser developed by Remy Sharp and available here.
For as long as I've been a jQuery user - going on 18 months now - I've been frustrated by the slow speed and sometimes intermittent availability of the jQuery documentation site. Now we've got a blazing-fast API browser that presents jQuery Core and jQuery UI side by side in the same cool interface. Better yet, it's available as an Adobe AIR app for offline viewing. Sweet!
I could quibble about the lack of bookmarkable URLs and the occasionally sparse documentation of corner cases. Instead, I'll just remain upbeat about this huge step in the right direction. No matter how intuitive jQuery's API, it's a powerful library whose roster of methods continues to grow. Nothing speeds up development faster than quick, persistent access to quality API documentation.
Topics: Adobe AIR, Ajax, Ajax library, Ajax toolkit, Javascript, jQuery
jQuery celebrated its third birthday Wednesday with the release of the brand-new 1.3 version. This latest release includes a bunch of cool new stuff which has already been discussed to death elsewhere. To me, however, the most interesting aspect of jQuery 1.3 is the movement of former plugin functionality to the core library.
Live events are a new twist on the venerable, and indispensable, Live Query plugin, while the upgraded, more granular effects queues were previously tackled by add-on authors. IMHO, this kind of migration is A Good Thing, providing greater parity with other core JavaScript and effects libraries (such as Scriptaculous's FX queue) while offering compelling feature differentiation (event binding throughout the full lifecycle of an Ajax page).
Topics: Ajax, Ajax library, Ajax toolkit, Javascript, jQuery, Scriptaculous

Ajax pros, especially in the Rails world, often know the Prototype and Scriptaculous JavaScript libraries inside and out. When faced with the prospect of writing on top of the competing jQuery framework, they may quickly stumble upon seemingly missing features.
The culprit? jQuery's less-is-more approach, in which advanced or specialized features come via plugins instead of the core library. The greater reliance on single-purpose plugins gives jQuery a lean footprint and a vibrant ecosystem, but they come at a cost. You often must rope in several plugins to accomplish things Prototype and Scriptaculous can do out of the box.
If you want to encourage your team to step out of the Prototaculous mindset, it helps to have a readymade list of plugins that approximate those libraries' core features. At this point jQuery and Prototype approach feature parity, but once Scriptaculous is in the mix, jQuery relies on multiple plugins to keep up with the Joneses. Here's a quick stab at how to trick out jQuery:
Topics: Javascript, Javascript Libraries, jQuery, Prototype, Scriptaculous
Many times open source projects are mute -- they have insufficient documentation. Good technical blogs can function as a sort of ad-hoc documentation. That's what I've tried to do, most recently with my series of posts on GWT and OpenSocial. Vinay, over at Web Technology I/O, often does the same. He's got a great post about Ray Cromwell's GwtQuery (JQuery-like syntax in GWT) and how to make it work.
I've been tinkering with this tool as well and am going to do my own writeup, but thought I'd give you all the heads up. BTW, according to Vinay, the compiled GWT JavaScript for GwtQuery clocks in at 712 bytes!! So much for GWT bloat.
I've been pairing with my colleague Noel Rappin on a cool Rails project lately, which has helped me turn a bunch of conceptual knowledge into real-world experience. I'm writing Ruby code, doing things the Rails way, and hewing faithfully to test-driven development.
I'm also returning to Prototype for my JavaScript needs after almost 15 months of daily jQuery use. The framework has matured nicely while I've been away. One surprise popped up today, however: Prototype 1.6 lacks the ability to simulate native browser events. jQuery offers this in the form of jQuery.trigger, which can simulate both native and custom events. But Prototype's Element#fire supports only namespaced custom events. (Read this mailing-list thread for more analysis.)
I did a couple hours of digging around today - including a trip to Scripteka - and haven't really found a canned, cross-browser solution to this issue. I'm looking for something that offers jQuery's native event firing in a tidy little Prototype extension. Anyone know of such a tool?
Topics: Javascript, jQuery, Prototype, rails, ruby
Now that I've got a few Ruby on Rails projects under my belt, I finally feel qualified to comment on Rails front-end coding conventions. As a UI specialist coming to Rails from the JSP world, I find a lot of room for improvement in the RoR approach to view-layer code. I love working on the non-view aspects of RoR projects, but I find I've got to do tons of cleanup at the ERB layer. Expect to see some open-source components from Pathfinder to help ease this pain. In the meantime, let me articulate my pain points:
If I'm filling a front-end role on a Rails project, most of the files I need are in /app/views and /public. I dig that. Likewise, I appreciate the underscore naming conventions for partials. However, I wish /layouts weren't just another subdirectory of /app/views. Layouts are inherently different from standard view templates. A better hierarchy within /app/views would help drive this home. Likewise, I wish partials and full templates each had their own directory within a specific controller's view folder. That would help keep directories manageable on big projects. The /public directory, on the other hand, offers just the right amount of organization.
This piece of news has brought about great cheer in the Web Developers community. jQuery has been fast gaining reputation in the world of web-development as a light-weight, flexible and easy-to-use Javascript library. Integration of jQuery with Microsoft's development platform should provide web developers with new capabilities and opportunities.
This is very smart move by Microsoft given the fact they have always hesitated to incorporate open-source technologies into their products. It is planning to ship jQuery with the ASP .NET MVC very soon. Integration with Visual Studio is something that is going to happen later. There are plans to enable intellisense support for jQuery in Visual Studio which would be really cool I think.
Some of the high-points of jQuery integration with ASP .NET could be :
image-source : www.webmonkey.com
I have posted a few links below that discuss more about what the MS-jQuery marriage means for the web development community and how it can make life easier for developers out there.
http://weblogs.asp.net/scottgu/archive/2008/09/28/jquery-and-microsoft.aspx
In last week's post, I introduced the linked multiselect widget I was asked to implement on a tight deadline for an unexpected project assignment. I showed some demo code in action and discussed the user experience issues that shaped my requirements. This week, I'll walk through the actual code - or at least my first pass at it.
Like a lot of developers who should know better, I sometimes shirk the technical design phase on quick projects, then regret it later. The code I handed off for this project got the job done, but it wasn't very DRY or elegant. Luckily, I've continued to refine it into something I'm not ashamed to blog about. Next week, I'll show off the final, refactored code and try to draw some conclusions about the entire experience. But first - the original, unrefactored code:
Topics: Ajax, Design Patterns, Javascript, jQuery
Last week I spent a couple of days lashing together a UI widget for a project that needed a little Ajax assistance. As always, I looked for an opportunity to learn something along the way, so I got signoff on using jQuery and some plugins I hadn't previously employed.
The result? A down-and-dirty mini-project that let me test drive Color Animations, jqModal and Low Pro for jQuery while employing tried-and-true solutions such as jQuery Templates and Live Query. What's more, the requirements for the widget itself left room for some careful consideration of user experience design.
In the end, I built a client-side demo in just a few days and handed it off to the project lead for integration with a complex back end. Now I'm free to refine my deadline-constrained code into something a little more OO and share the results.
This week, I'll talk about the project's complex usability requirements and Pathfinder's user-centered solution to those requirements. Next week, I'll walk you through our first pass at building custom code, roping in open-source libraries and making it all work together on a tight deadline. Finally, I'll walk you through the refactoring process so you can see the final, properly factored and reusable version.
Topics: Ajax, Javascript, jQuery, Low Pro, OOP

Drag and drop is like those Nutty Bars snack things.
Allow me to explain.
I like Nutty Bars. But I never expect to like them. They are kind of funny looking, for one thing, what with that weird criss-cross pattern on the top, and the chocolate never quite covering the wafers. But when I get past that and actually eat one, it's actually kind of tasty.
Which brings me to drag and drop. Which I always expect is going to be an overwhelming pain in the neck (probably based on bad experiences using Java Swing). But whenever I manage to get over it and actually implement a web drag and drop, I'm always surprised at how easy it is using an Ajax framework.
jQuery is no exception.
Topics: Javascript, jQuery, Project Website, Ruby on Rails
Yesterday I discussed how to separate the jQuery plugin wheat from the chaff. Today, I offer a completely subjective and biased list of jQuery plugins to know and love.
Topics: Ajax, Javascript, jQuery, plugin
I opined recently that jQuery plugins can be more trouble than they're worth. That said, they're often indispensable. True, the worst plugins suffer from bloated code, confusing APIs and too many features. But the best provide instant black-box functionality with just a little configuration. The trick is figuring out which plugins are worth the effort and which ones aren't. Here are five tips for doing just that.
Topics: Ajax, Ajax libraries, Javascript, jQuery, plugin

This is something of a mix between what I've been doing on the http://www.pathf.com/blog/tag/project-website/ posts with my more typical "here's how you do something in Rails" post. I'm going to describe how to use jQuery to manage JavaScript and Ajax in a Rails application rather than Prototype and Scriptaculous.
The benefits of using jQuery on a Rails project seem to be:
There are a couple of costs, especially from a Rails application
assert_select_rjs and the lack of unit testing of jQuery behavior. As much as JavaScript development tools have improved, there are still gaps in testing browser-centric behavior.Topics: Javascript, jQuery, Project Website, Ruby on Rails
Part 3 of my colleague Brian Dillard's series on retrofitting your web site with Ajax is now up on the IBM Developerworks site.
In this installment, you'll tame unmanageable product-details pages by placing content inside a tabbed interface. You'll also keep product images under control by displaying them in an image carousel. You'll learn how to employ both techniques using simple Dynamic HTML (DHTML) or more complex Ajax code. Either way, you'll again use the principle of progressive enhancement to keep your pages accessible even when JavaScript isn't enabled. To accomplish all this, you'll use two additional jQuery plug-ins: jCarousel for image slideshows and jQuery UI Tabs for tabs.
You'll also want to look at parts 1 and 2.
Topics: Ajax Development, Announcement, jQuery
I recently asserted that open-source plugins are sometimes more trouble than they're worth. Nevertheless, I've found one unexpected benefit of jQuery's plugin mechanism: its ability to keep me focused on reusable components rather than one-off, procedural routines.
Because jQuery doesn't ship with any general-purpose way of simulating classical inheritance, it's easy to fall into the trap of writing procedural code with no eye toward re-use. When your first pass at solving a given problem often takes only a few lines of code, it seems like too much overhead to wrap those lines in any sort of object.
But then you decide to layer on some effects ... or there's a new requirement to retain state across sessions by calling on a cookies plugin ... or you end up with a new use case that would require a subclass of your existing code - if it had been written as a class in the first place. By this point it becomes obvious that your behavior layer is poorly organized, hard to maintain, and inexorably tied to a specific use case. That's when you roll up your shirtsleeves and start refactoring.
Topics: Ajax, Javascript, jQuery