Very often, different controllers require different javascript, and while you could just put all your javascript in your application.js file, this doesn’t doesn’t lend itself to anything more than the most basic of applications. It becomes very large, and hard to maintain.
The solution I use is to include any global javascript (prototype etc) in my application.rhtml and then use the controller name to load any specific javascript
<%= javascript_include_tag ‘prototype’ %>
<%= javascript_include_tag “application” %>
<%= javascript_include_tag controller.controller_name %>
The problem starts when you throw something like Yahoo’s YUI framework into the mix, with it’s many components and javascripts you can easily add some serious overhead if you include every one in the global application, the ones you don’t need just bloat your application and slow down page loads.
In the past, in other languages I’ve always solved the problem by passing the required libraries into the XSLT and letting it transform that into script tags, You could construct and array and use that in the view to load the various bits of javascript.
The engineers at Yahoo! have obviously run into the same problem, and recently introduced the YUILoader component, which lets you load any javascript the page may require, and if that happens to be YUI components, it’ll also load any dependencies they require too. This is also a great way of integrating YUI with rails, without bloating your app, and without creating convoluted bespoke solutions.
To start with, you need to include the YUILoader itself in your applications view, but before we go any further, I’ll just point out that while you can use the Yahoo! hosted versions and probably should, for development I prefer to have a local copy to use just in case net access isn’t available. I put a copy (actually, I symlink it.) in public/javascript/yui, my application.rhtml has something like this in it:
<%= javascript_include_tag ‘prototype’ %>
<%= javascript_include_tag “application” %>
<%= javascript_include_tag ‘yui/yahoo-dom-event/yahoo-dom-event’ %>
<%= javascript_include_tag ‘yui/yuiloader/yuiloader-beta’ %>
<%= javascript_include_tag controller.controller_name %>
You don’t need to include yahoo-dom-event, but if you don’t YUILoader will try and grab it from the internet, regardless of where you tell it ‘base’ is.
In your ‘controller_name.js’ you need to initialise the loader, tell it what to load and finally tell it what to do once it’s loaded them.
var init = function()
{
var loader = new YAHOO.util.YUILoader({
require: ['container', 'element', 'button', 'calendar'],
onSuccess: function() {
// Put your code here to initialise any
}
});
loader.insert();
};
// Use whatever method you like to make sure the page has finished loading.
YAHOO.util.Event.addListener(window, ‘load’, init);
This way you can seperate your javascript into seperate files to match your controllers, and keep your app lean by only loading the javascript you need, when you need it.
6 Comments so far
Leave a comment
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <pre> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>


Hi Stuart,
thanks, this works well for me!
One minor typo in your init function:
it should be:
var loader = new YAHOO.util.YUILoader
instead of
var loader = new YAHOO.utilYUILoader
Cheers
Comment by Benny Beesnuts March 5, 2008 @ 1:13 pmBen
Thanks Benny …
Comment by Stuart Grimshaw March 10, 2008 @ 10:05 am[...] Integrating YUI with Ruby on Rails. « Stubblog (tags: yui rails javascript lazycoder) [...]
Pingback by links for 2008-03-14 | Lazycoder March 14, 2008 @ 10:21 am[...] are a number of tutorials out there for this — Stuart Grimshaw has one method in this article , but an easy way is to use the YUI configuration tool and just serve the files from their CDN [...]
Pingback by Instant Shiny Forms with Rails and YUI « Enleitened June 7, 2008 @ 6:19 amNice post, I am giong to try it shortly.
Comment by stephen October 6, 2008 @ 6:08 pmJohn sums up telepresence from a network perspective, “Telepresence is an interactive real- time application, which means it is delay sensitive, loss sensitive and jitter sensitive. This sounds familiar: it is just like VoIP, with the one difference being that it has huge bandwidth requirements.” It’s that last part that makes things more difficult. No form of QoS can allocate bandwidth that doesn’t exist and it doesn’t have provisions to force the application to downscale the experience based on realtime metrics. …
Comment by application acceleration December 15, 2008 @ 9:15 am