Posts Tagged ‘jquery’

jQuery in Joomla: I was wrong

For quite some time now, it’s been no secret that I’m a fan of jQuery and prefer it to MooTools for JavaScript development. However, Joomla ships with MooTools as the preferred JavaScript framework. Both jQuery and MooTools like using $ as a shortcut method name, which can cause conflicts. Fortunately, both frameworks have ways of disabling this shortcut so that you can use them side by side.

Unfortunately, if you’re not paying attention to the ordering of the JavaScripts, you can end up loading both before you have a chance of sending one into “no conflicts” mode. For quite some time now, I’ve advised fellow Joomla developers to always load MooTools first. It turns out that this advice is not correct, and can cause you to load up MooTools when you’re not even going to use it.

So I’d like to explain why I came to this conclusion in the first place, the correct way of avoiding the problem, and a call to solve this centrally so that people don’t have six copies of jQuery loading on their websites.

The real issue

The core issue has to do with the way JDocument adds JavaScript to the HTML document. As you call JDocument::addScript(), JDocument makes an internal list of all the JavaScript files it needs to load. Also, calling JHTML::_(‘behavior.mootools’) adds the MooTools framework to this list. You can also pass JavaScript in a string to be added directly in <script> tags through the JDocument::addScriptDeclaration() method. With these methods in mind, you would assume that you could add jQuery via JDocument::addScript() and the JavaScript snippet ‘jQuery.noConflict()’ through JDocument::addScriptDeclaration(), like this:

$document = JFactory::getDocument();
$document->addScript('path/to/jquery.js');
$document->addScriptDeclaration('jQuery.noConflict()');

This sometimes works. However, if (for instance) your module used jQuery and the next one used MooTools, you’d run into a conflict even though you had $document->addScriptDeclaration(‘jQuery.noConflict()’) in your code. The advice passed around by myself and the Joomla community was to do this in your code:

JHTML::_('behavior.mootools');
$document = JFactory::getDocument();
$document->addScript('path/to/jquery.js');
$document->addScriptDeclaration('jQuery.noConflict()');

This ensured that MooTools got loaded first and that the conflict would not happen. This also forced MooTools onto the page regardless of whether or not it was being used. It turns out this approach doesn’t really address the real problem: Joomla loads all of your external scripts first, then loads all of your script declarations. So for instance, the following code snippets result in the same script ordering as the previous sample:

$document = JFactory::getDocument();
$document->addScriptDeclaration('jQuery.noConflict()');
JHTML::_('behavior.mootools');
$document->addScript('path/to/jquery.js');

$document = JFactory::getDocument();
JHTML::_('behavior.mootools');
$document->addScriptDeclaration('jQuery.noConflict()');
$document->addScript('path/to/jquery.js');

The fix

To genuinely solve the problem and not worry about MooTools, you need to first create a JavaScript file with the code jQuery.noConflict();. Then you need to load jQuery, then load the file containing the jQuery.noConflict(); code. Your code in Joomla would look like this:

$document = JFactory::getDocument();
$document->addScript('path/to/jquery.js');
$document->addScript('path/to/jquery.noconflict.js');

In this example, jquery.noconflict.js contains the following code:

jQuery.noConflict();

By doing this, it’s guaranteed that jQuery.noConflict() will get called immediately after jQuery is loaded by the browser. To recap, the ordering of MooTools and jQuery does not matter if you make sure jQuery.noConflict() is called immediately after jQuery is loaded. After you send jQuery into noConflict mode, you still must either use jQuery() instead of $(), or use one of the referencing methods described here in your jQuery-powered code.

But wait, I still have a thousand extensions all loading jQuery!

Ideally, each Joomla site should be loading either zero or one copies of jQuery. Having multiple copies of jQuery sitting around Joomla puts site owners in the position of having to manage conflicts. Also, distributing multiple copies of jQuery discourages the use of Google’s JavaScript library CDN. We don’t want to foist this problem onto site administrators; they just want all of their extensions to work.

Fortunately, there’s an effort underway to standardize and document the use of jQuery in Joomla. If you’re willing to help out, join our Joomla People Group jump into the discussion. We should be able to document a way for extension developers to bundle a jQuery plugin with their extensions, as well as avoid version conflicts. Ultimately, a copy of jQuery should be installed and updated as necessary without the intervention of site administrators.

Using MooTools and jQuery Together in Joomla!

Framework conflicts are a common problem people run into when using jQuery. While jQuery provides some tricks you can use to get around this, you may still run into issues when Joomla! generates MooTools effects. While writing the second edition of Learning Joomla! Extension Development, I decided to do a chapter on JavaScript and look into this problem a little bit more closely. It turns out you have to make sure MooTools loads before jQuery, then use one of the tricks detailed on jquery.com.

Fortunately, this can be done in Joomla! consistenly, so I documented it. Packt decided to release the entire JavaScript chapter as the sample PDF for my book, so you can read everything you need to know about implementing this technique for free!

Chinese New Year’s resolutions

In January, my New Year’s resolution was to make more resolutions today: Chinese New Year. Solely because Chinese New Year is more than a month later.

So here goes:

  • Go electronic/automatic with as much of my record keeping and business handling as possible. There are a lot of things I could be doing electronically but have still been doing on paper or through the mail. Also, I need to come up with a better system for handling recurring tasks and scheduling. If it comes down to it, I may end up with one of these or these. (sigh)
  • Rewrite the Daily Message tutorials, Podcast Suite, iWebCal, and my book to catch up with Joomla! updates. The latter should come out first.
  • Validate all of the markup on jlleblanc.com. Last year, I finally got on the whole semantic web bandwagon and haven’t fallen off yet. What was the catalyst for all of this? jQuery. When I saw how it was all CSS selector-based, DOM programming and the benefits of validated markup simultaneously made sense. The pursuit of validation is also helping me maintain Section 508 compliance at work.
  • Blog more and worry less about writing essays. When I started blogging, I actually wanted to start a site where I would keep a repository of opinions on specific topics, refined over time. This doesn’t really seem to work as people are much more familiar with off-the-cuff blog posts.
  • Incorporate.
  • Launch a major web-based service. Oh, so you’d like to know what’s cooking at Chez LeBlanc? You’ll just have to wait and see ;)

Some software I’ve been using recently

Flot – Want to build dynamic graphs without using Flash? Flot is ready. It’s lightweight and pretty quick to pick up. I’m using it for a project where people can add and remove as many data series as they wish. Throw in some JSON calls and the results are pretty impressive. Although I can’t show off that project here, take a look at some of the posted examples. It’s based on jQuery and produced by a Danish firm.

MacFUSE and SSHFS – One of the biggest problems I’ve run into with using Macs is that Finder cannot mount FTP and SFTP sites as writable volumes. While you can get clients like CyberDuck that will allow you to do transfers, editing the files for an entire website this way can be tedious. Using MacFUSE and SSHFS together can get around this limitation. SSHFS is still in a very early release and I did run into some stability issues when mounted all day long, but the core functionality is there.

Selenium IDE – Testing and debugging web interfaces has always been a bit of a pain, but Selenium IDE can make the process much, much faster. Open up the IDE, click record, then start filling out forms and clicking on elements. Then you can save your test and reopen it later to run it whenever you wish. I did run into a few issues where Javascript generated DOM elements confused the debugger (might be a timing issue), but overall it is a very powerful and easy to use Firefox extension. You can also use Selenium Core on other browsers. I haven’t tried this, but it appears that you can record the test using the IDE in Firefox, then use that same test with Core with the other browsers. Thanks to Laura Thomson for mentioning this one at the DC PHP Conference this past fall.