Thought Delimited

NOT doing the tip that I'm about to share has bitten me twice now, so I'm putting this out there as a reminder to myself as well.

The jQuery live() function is an extremely useful function to have when you're adding or removing page elements that have jQuery event handlers assigned to them because using live() ensures that any new element that matches the live() selector gets that event handler automatically.

It's easy to remember to use live() when you're writing your own code that adds and removes DOM elements, but when you're using a plugin that does the adding and removing behind the scenes, you might not think about it.  In one of my applications, I apply the jQuery DataTables plugin to my HTML tables so that the users can sort and filter the data in the tables.  Included in each row are hyperlinks that trigger certain actions via JavaScript/jQuery. 

When I originally assigned the event handlers to these links, I simply used the "click" event handler on them.  The links worked perfectly if they were displayed as part of the initial page load, but any links belonging to rows that appeared later (as the result of a sort, filter, or pagination event in the plugin) did not work because the link elements were actually added by the plugin, and hence did not have the event handlers assigned to them.

In short, if you're using one of the many plugins to enhance HTML tables, and you have elements in each row that have jQuery events assigned to them, make sure you use the live() function to assign those event handlers.

The focus of the jQuery UI Meetup I attended last week was on jQuery UI 1.8 and to work out some questions regarding future meetups, but of course some other topics came up as well. One of those other topics was the not-uncommon problem of having certain HTML content, meant to be hidden or styled by jQuery, briefly appearing in its raw form before the page has fully loaded and jQuery gets to do its thing. Apparently the term for this phenomenon is "FOUC", which stands for "flash of unstyled content."

Now, if you took it as an absolute that any and all uses of your web page had Javascript enabled, you could solve a FOUC problem by assigning a CSS style to the problem content that hid the content right from the get-go, and then you could use Javascript to reveal the content at the appropriate time. But such a solution would fail if the user had Javascript disabled--the content would never be visible to them--and it's contrary to the idea of progressive enhancement (the idea that the page is usable as is, but is enhanced when Javascript is available).

So in answer to the question on FOUC, Richard Worth (the speaker for the meetup) pointed us to the following blog post by Karl Swedberg:

http://www.learningjquery.com/2008/10/1-way-to-avoid-the-flash-of-unstyled-content

The post provides a pretty good explantion of the technique (which is pretty simple), so I don't feel the need to explain it or add to it. Just thought I'd put it out there because it would be hard to find via a web search if you didn't know how to describe the problem and didn't know the FOUC acronym.

This past Wendsday, I attended the first jQuery UI meetup at the Microsoft office in downtown Washington D.C. The sole presenter for the meeting was Richard Worth, one of the members of the jQuery UI development team, who spoke to us about the new features in the latest release of jQuery UI, version 1.8...and mentioned a few things that were planned for the next release.

Read more...

The members of the jQuery team announced today that they're going to be making a series of announcements and content releases leading up to the release of jQuery 1.4 on January 14th.  They've put up a website, The 14 Days of jQuery, where you can keep track of all that's going on.

I don't know what all they've got planned, but I was really impressed with today's announcement:  the release of a new jQuery API site.  The new site is http://api.jquery.com, and it looks to be a much-improved replacement for the current http://docs.jquery.com site, with a cleaner look, better organization, more descriptive entries and examples, and even a comment/feedback mechanism.

They've also made all of the information on the new API site available in a single XML document (http://api.jquery.com/api), allowing folks to grab that data and make their own custom tools for researching/referencing jQuery.  I may have to get in on that action...  :)

Anyway, it sounds like the next 14 days are going to be interesting if you're a jQuery fan.

I happened to stumble across a blog post today by Phil Haack with the title "Death to confirmation dialogs with jquery.undoable." In it, Phil explained how he was inspired to write his plugin by seeing how his Netflix queue allowed him to "undo" the deletion of an item from the queue. As he said in his post:

"Notice that there’s no confirmation dialog that I’m most likely to ignore questioning my intent requiring me to take yet one more action to remove the movie. No, the movie is removed immediately from my queue just as I requested. I love it when software does what I tell it to do and doesn’t second guess me!"

His post got my attention because I'm currently in the middle of designing a scaffolding/code generation system, specifically to output pages for performing CRUD (Create, Read, Update, Delete) tasks, and it's currently designed so that when the user clicks on a "delete" link for a record (and Javascript is enabled), I make the user confirm their decision via a customizable dialog box (via the jqModal jQuery plugin) before proceeding with the deletion.

So I got to thinking about what would be involved in doing what he was suggesting: allowing the user to "delete" a record without confirmation as long as they had the option of undoing that action while still on the page.

I put "delete" in quotation marks because such a process would almost certainly involve making the delete a "soft" delete: marking/tagging the record as being deleted but not actually deleting the underlying database record. Undoing an actual deletion would be much harder, given that you would lose the unique record id in the deletion in addtion to the rest of the record data. I suppose you could potentially store the data from the record client-side (in the page) so the "undo" record could recreate the record from scratch, but that would be a pain and might not be feasible in every scenario. Undoing a soft delete/changing the delete flag in the record, on the other hand, would be pretty easy.

But if I went the soft delete routine, then the question would become: how do those records get deleted for real? I tend to design my web applications with a long term view, and I don't want the application database tables to fill up with deleted records over a number of years. My clients typically only have access to the database tables via the application itself, so leaving that up to them is not an option. So I would either have to given them another page/tool in the web application (perhaps a tool restricted to a tech-savvy few) to actually remove the deleted records, or perhaps run a scheduled task to remove those database records that have been marked for deletion for a year or more.

After some consideration, my current inclination is to stay with my current confirmation dialog/deletion routine. In most of my applications, the CRUD interactions are reserved for the administrative users of the application, who typically know when it's appropriate to delete a record. And the need to delete a record via the CRUD tools provided is usually rare, so having a confirmation dialog come up for each instance isn't too much of an annoyance.

But I'd be curious to hear other people's thoughts on this topic.