So there was this need for providing ajax-style add/remove item-rows on the last project I worked on. What I thought might be pretty straight-forward to achieve using jQuery-fu eventually turned out to be little hairy for me.
Read more »
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.
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).
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:
Read more »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.
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?
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.
Read more »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:
Read more »
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.
Read more »