Antelope Love Fan

I occasionally run into a scenario where I have to run jQuery and PrototypeJS on the same site.

Usually this is because it’s an older site that was original written using Prototype and we’re migrating it over to jQuery. Or other times it’s just easier to use an existing jQuery plugin for something than to write a few dozen lines of Prototype from scratch.

It’s easy to run jQuery in parallel with other libraries thanks to jQuery’s noConflict mode which makes jQuery stop using the $ variable.

“But”, you say, “Having to type jQuery.whatever() over and over is so hard compared to typing $.whatever().”

Well, my friend, today is your lucky day. I have a solution for you that will save you characters of typing. Characters!

If all of your code is happening inside of a jQuery.ready() event, you can do this:

  jQuery(document).ready( function($) {
    $('a’).css('border’, '1px solid red’);
  });

In the example above, jQuery is passing itself to the ready() function handler. That means any code instead the ready handler can use $ to access the jQuery object.

And if your jQuery code isn’t inside a ready() event? Still easy to handle:

(function($) {
  function makeAllLinksRed() {
    $('a’).css('border’, '1px solid red’);
  }
})(jQuery);

In this case, we wrap all of our code in an anonymous function that calls itself, passing in the jQuery object as a single parameter. Now all of the code inside the anonymous function can use $ to access the jQuery object.

Have you ever gotten this error when using jQuery to handle DOM events?

Can’t load XRegExp twice in the same frame

In many cases, I’ve found that to be caused by code like this:

$(‘a.foo’).click( function() {
  alert(‘You clicked on me!’);
});

when a.foo doesn’t exist in the DOM yet.

The fix? Use jQuery.live() to bind to the event.

$(‘a.foo’).live( ‘click’, function() {
  alert(‘You clicked on me!’);
});

---

I’ve also run into a couple of situations where Chrome Extensions for formatting JSON & XML also caused this error in some cases. Disabling those extensions also fixed the error.

Thanks to this Stackoverflow answer for the suggestion.

Let’s say you have a Postgres database with a table that looks like this:

thing_id	unix_date
1	1253764800
2	1253804507
3	1253764810
4	1253764801

See how unix_date field is a Unix timestamp?

Well what if we want to deal with it as an actual Postgres date type?

Turns out it’s pretty easy with the following SQL:

SELECT
*,
TIMESTAMP 'epoch' + unix_date * INTERVAL '1 second' as real_date
FROM mytable