Thought Delimited

In addition to providing a number of standard validation rules, the jQuery Validation plugin also allows you to create your own validation rules via the addMethod() function.  Today I had a situation where I had to use that function:  I had to create a rule to ensure that the end date of a date range determined by the user was later than the starting date.  I thought I'd share what I came up with.

The details of the situation:

• The user set the starting date using two radio buttons and a text field bound to the jQuery UI Datepicker.  Selecting the first radio button meant that the start date (the "now" button) should be set to the current date, while selecting the second radio button (the "later" button) meant that the starting date would be determined by the value in the Datepicker field.
• The user set the ending date using another Datepicker-bound text field.
• The Datepicker plugin ensures that the date is always in the format "mm/dd/yyyy".

Here is the code:

jQuery.validator.addMethod("dateComparison",function(value,element) {
    var result= true;			
    if($("#startDateOptionLater:checked").length== 1) 
      {
        var dateArray= $("#startDate").val().split("/");
        var startDateObj= new Date(dateArray[2],(dateArray[0]-1),dateArray[1],0,0,0,0);
      } 
    else 
      {
        var exactDate= new Date();
        var year= exactDate.getFullYear();
        var month= exactDate.getMonth();
        var day= exactDate.getDate();
        var startDateObj= new Date(year,month,day,0,0,0,0);
      }
				
    var endDateArray= $("#endDate").val().split("/");
    var endDateObj= new Date(endDateArray[2],(endDateArray[0]-1),endDateArray[1],0,0,0,0);
    var startDateMilliseconds= startDateObj.getTime();
    var endDateMilliseconds= endDateObj.getTime();
				
    if (endDateMilliseconds <= startDateMilliseconds) 
      {
        result= false;
      }
     
    return result;

 },"The ending date must be a later date than the start date");

So if the user selected the second start date option and chose a date using the Datepicker widget, the code splits up the date string into an array and uses the individual month, day, and year values to create a Date object. If the user selects the option of making today the starting date, a new Date object is created (which by default has the value of the current date and time) and the code creates a new Date object with the same date but with the time-specific data stripped out (because the end date will not have a time value attached to it).

The Date object for the end date is created with the same technique used for the second start date option, and then the getTime() function is used on both the start and end Date objects to get the number of milliseconds between each date and January 1, 1970 (a starting point for date and time values used in both JavaScript and Java). Then it does the comparison between the two dates.

It's then a simple matter of applying this custom method somewhere within the normal jQuery Validation rules block:

...
rules: {
    endDate: {
      required: true,
      dateComparison: true
    }
...

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.