Ampersand has received a lot of presslately and I decided to put my oar in as well.
My recent history with ampersand is kind of embarrassing, to say the least. I was giving a Ruby class in UK a few years back and during a class, I asked a participant whether there is some other term for the at sign in English. “Sure”, she said, “it’s ampersand.” To this day I’m not sure whether she thought I said et sign, or genuinely mixed up asperand and ampersand. But for quite some time after that, I happily treated @ as ampersand.
But neither linguistics or typography is the topic of today’s article. Let’s rather talk about ampersand (the real one) in Ruby.
In Ruby, an ampersand denotes a block parameter. But let’s not get ahead of ourselves. A little background might be in place.
One of the coolest features in Ruby are code blocks, or closures. They are basically anonymous functions, but as pretty much everything in Ruby, they are also objects. They are anonymous functions, that have little use just by themselves. However, you can turn them into Proc objects either with the Proc.new constructor or using the lambda kernel method. The common best practice to mark code blocks is to use the curly braces with one-liners and do..end with blocks that span multiple lines:
yell = lambda { puts "AAARGH!!!" }
whisper = Proc.new do
puts "whee"
end
yell.call
whisper.call
?
AAARGH!!!
whee
Maybe the most useful application of Proc objects in Ruby are block parameters. Anyone with some knowledge of Ruby is familiar with the following:
>> arr = %w(apple orange kiwi)
=> ["apple", "orange", "kiwi"]
>> arr.each {|i| puts i[0,2]}
ap
or
ki
=> ["apple", "orange", "kiwi"]
As you can see, in this case you need to use neither Proc.new nor lambda with the block; it’s converted to a Proc object implicitly. But as the method receives just a Proc object as its parameter, you could also say something like this, right:
Err, not quite. It turns out Ruby methods can take two kinds of parameters—a number of normal parameters and a block parameter. In the code above the interpreter will think that the put_twoProc object is passed as a normal parameter to the each call, and since each doesn’t take any normal parameters, you will get an error:
>> arr.each(put_two)
ArgumentError: wrong number of arguments (1 for 0)
from (irb):42:in `each'
from (irb):42
And this is what brings us back to the ampersand:
>> arr.each(&put_two)
ap
or
ki
=> ["apple", "orange", "kiwi"]
So the ampersand is used to tell the interpreter that the following reference is the block parameter of the method.
One fairly common idiom in the Rails world is this kind of construct:
>> arr.map(&:length)
It is effectively the same as
>> arr.map {|i| i.length }
=> [5, 6, 4]
However, if you start a plain irb session, you will notice something isn’t quite right:
>> arr.map(&:length)
TypeError: wrong argument type Symbol (expected Proc)
from (irb):2
That’s right. The cool shorthand method that worked so nicely in your Rails app doesn’t work in plain Ruby. That’s because there is some Rails magic behind the &:method call. This magic is e.g. the reason why Ezra has prohibited using the shortcut in Merb framework code.
But let’s have a closer look at what’s actually happening behind the scenes in the shortcut. The thing that’s different from our earlier calls is that there is a colon between the ampersand and the word “length”. This means that we’re not using a variable or method called length, but the symbol :length. If you’re not familiar with Ruby symbols (or even if you are), reading Josh’s recent article on symbols is a worthwhile read.
Now that we know that we’re trying to pass a symbol as the block parameter to a method (and that it’s not really working, as the error above indicates), we need a way to convert it to a Proc object like expected by the method. Ruby has a slew of type conversion methods that are called implicitly whenever it’s clear that a certain type of object is needed. Inside a string for example, to_s is called automatically for every object that is not a string itself:
In the same vein, since a block parameter of a method needs to be a Proc object, to_proc is called automatically for all other objects in an effort to get a hold of a proc. So could it work if we just added a to_proc method to the Symbol class? Let’s find out!
class Symbol
def to_proc
lambda {|i| i.send(self)}
end
end
Here we make to_proc a lambda function that will use the send method to call the method with the same name as the Symbol object in question (self) for the element that’s passed to it.(That got too confusing so let’s just use examples). So
While Symbol#to_proc is a clever and perhaps an elegant hack, it’s still kind of a hack. So should you use it in your code? I tend to side with Ezra on this. If you’re writing framework code, you should probably err on the side of readability and common usage, and thus avoid “magical shortcuts” like these. But in application code, why not. I certainly do.
Turns out capistrano is for some reason trying to use a user called app in the cleanup task even though the :user parameter is set to something else in config/deploy.rb. The solution was to set the :runner parameter as well:
set :runner, 'someotheruser'
Don’t ask me why that worked. It seems a bit counterintuitive that the cleanup task uses the runner param rather than user. Found the hint towards the solution here.
For gawd’s sake, what did they smoke in your company’s Christmas party?
(A text message I sent to my buddy Thomas who works in Sampo Pankki in reference to the news that the bank (recently bought by Danske Bank) would deploy a new “security” system (that uses a Java applet) in their online banking solution).
April 2008
The latest reactions inclule [sic] 52-year old male customer returing to the bank with an axe after hearing that his account is empty, money exchange company Forex stopping accepting payment cards from Sampo Bank and Sampo Bank customers not being able to buy train tickets online.
One of the most interesting topic in the discussion is about human multitasking, and to be precise, the lack of it. One of the hot topics in this discussion is the debate about talking in phone while driving. Medina brings up recent studies that show talking while driving is as dangerous as drunk-driving, no matter whether you use a hands-free set or not. As a reason, Medina proposes that when discussing with someone remote interactively, you build a mental image of the counterpart (just like you do when reading a novel) which takes your concentration away from driving. That sounds certainly believable. I have many times noticed that I’ve been driving for minutes while talking in the phone (with the iPhone headset, of course) and then suddenly kind of wake up back to the traffic.
If you’re into photography, here’s a couple of quick links that might be of interest:
Scott Bourne and Alex Lindsay, of MacBreak Weekly and many other fames, have started a new podcast under the Pixelcorps.tv umbrella: This Week in Photography. The guys are really great podcasters and the content is kind of semi-advanced so that it’s not boring even if you’re fairly competent (even pro, I would say) but also not overwhelmingly technical. Great stuff during long exercises like a track of two1. The third episode of TWIP discussed the state of Aperture and namely the lack of announcement of version 2 during the PMA. That gives us a nice segue to the next topic:
Aperture 2 is here! Downloading it right now and have high hopes for the performance. Especially creating previews and exporting photos leaves a lot to be desired in 1.5, and if the first comments around the ‘net are to be trusted, the newcomer should be vastly better in this regard.
1 A track of two (or “kakkosen latu” in Finnish) is a term that came from a two-hour cross-country skiing (preferably classic) exercise and is now a synonym for any longer training pass (run, ski, hike, whatever) of around or over two hours.
I’m kind of sad that Blu-ray has taken the lead in the next generation digital video disc race, and that has little to do with the fact that I don’t really like Sony. The reason the lurking death of HD DVD makes me really sad is that while it has smaller capacity than BD, it has one thing really going for it: it’s void of one of the pests of modern times: regional codes.
Jeremy Keith recently wrote about DVD’s and Wii games that he bought during his Christmas trip to US that he cannot use because they are limited to be played only by a player with the US region code. Now, there are region code-free players available, but that only makes the whole scheme more pointless.
Now, with HD DVD being free of the region codes, we could have gotten rid of them once and for all. However, with Blu-ray seemingly winning the war, we seem to be stuck with the same hassle into the unforeseeable future. And people wonder why Pirate Bay is the #1 movie distribution channel in Europe these days…
I just run into the following error when running autotest within a Rails app:
/Users/jarkko/Sites/koulutusweb/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:402:in `to_constant_name': Anonymous modules have no name to be referenced by (ArgumentError)
from /Users/jarkko/Sites/koulutusweb/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:214:in `qualified_name_for'
from /Users/jarkko/Sites/koulutusweb/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:477:in `const_missing'
from /Users/jarkko/Sites/koulutusweb/vendor/plugins/rspec/lib/spec/example/example_group_factory.rb:7:in `reset'
from /Users/jarkko/Sites/koulutusweb/vendor/plugins/rspec/lib/spec/example/example_group_factory.rb:59
from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in `require'
from /Users/jarkko/Sites/koulutusweb/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in `require'
from /Users/jarkko/Sites/koulutusweb/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:342:in `new_constants_in'
... 59 levels...
from /Library/Ruby/Gems/1.8/gems/rspec-1.0.8/lib/spec/runner/command_line.rb:17:in `run'
from /Library/Ruby/Gems/1.8/gems/rspec-1.0.8/bin/spec:3
from /usr/bin/spec:19:in `load'
from /usr/bin/spec:19
It turned out I had typed “sudo gem update zentest” to get the latest version of the gem. However, the correct way would have been to use the camel-cased version ZenTest. The funny thing is, that if you run the command in lower case (like I’m use to do with RubyGems), you will get ZenTest, it’s just version 3.5.0 (as opposed to 3.8 that I supposedly got).
So here’s hoping that the next time I do the same mistake, this page will pop up from the big G.
Last weeks, the air has been thick about even Sony BMG, the last of the big four music labels finally abandoning it’s rootkit-stained history of draconian DRM schemes and publishing “at least part of its collection available DRM-free. However, the actual way of how it’s going to happen has been unclear until very recently. And boy, what scheme that came to be:
The No. 2 record company after Universal Music will sell plastic cards, called Platinum MusicPass, for individual albums for a suggested price of $12.99. Buyers enter a code from the card at new Sony BMG (SNE) site MusicPass.com to download that card’s album.
To get Sony BMG’s DRM-free music files, someone burns some coal to manufacture these petroleum-based plastic cards, then delivers them to stores on a series of diesel trucks. I drive to Best Buy in my 3056-pound gas-burning car and find my particular little plastic card, assuming that store carries the album I want in plastic-card format and it’s in stock. (If not, I need to drive to more stores, or just give up and try again next weekend.) But they probably have these cards taking up space somewhere in their massive store that requires tons of energy to keep well-lit and ventilated (since it has no windows).
And as far as the “part of the collection” part goes, the DRM-free collection will be a whopping 37 albums. Three-seven. Combining the convenience of going to a store to be able to buy tunes online, and the width of the supply, I’m sure people will be buying the albums like crazy.
Kid #2: So to recap, what you’ve got here is a system that makes people leave their house in order to download music at their house, and makes them go to a store to get music that they could get at the store, somewhere else.
Sony BMG dude: Er.
Kid #1: Why don’t you just sell non-DRM’d MP3s off Amazon, like every other major music corporation?
Sony BMG dude: Well.
Kid #2: You don’t actually want to sell unprotected MP3s, do you? You want to be able to say you’re doing it, but really, you want to make it so ridiculously inconvenient that people keep just keep buying CDs and DRM’d tracks off iTunes. Just admit it, bro.
Sony BMG dude (pointing): Look! It’s Celine Dion! And Barry Manilow! (runs away as kids avert their eyes in terror)
Won’t they ever learn?
[UPDATE:] They will indeed start selling music through Amazon MP3, according to MacWorld. The question remains, why on earth did they publicize the born dead plastic card scheme if the whole Amazon deal was about to be announced. The other question is, doesn’t it sound like a cartel that three of the big four labels refuse to sell Apple DRM-free songs but sell them somewhere else? Let’s hope there are some announcements coming next week in San Francisco.
It’s hard to write a full book for a seasoned Rails hacker nowadays. Most of every tutorial-like tome will be fluff and even if there are some useful tidbits to gather, they’re often hard to find among the sea of surely useful but hardly nouvelle information. That’s why I really enjoy reading concise, to-the-point articles about specific solutions, and there is a genre of books that are chock-full of those nifty solutions: the cookbook style books. Chad’sRails Recipes, Lucas’s and Leonard’sRuby Cookbook and Rob’sRails Cookbook have often made my day when even the mighty G has failed.
And now, fresh from the pragmatic oven, prepared with tenderness and love by Mike Clark and a slew of contributors, comes Advanced Rails Recipes. From a quick look through the beta PDF (available for purchase now through the beta book program), this will surely be one of the most useful Rails books for an advanced hacker ever written. Mike has managed to gather a respectful pile of recipes from experienced Rails people like Ezra, PJ and Chris, Adam, Giles and many, many more. Getting access to all these people’s heads within one book is something really unique and privileged.
Disclaimer: Advanced Rails Recipes contains a recipe written by me, “Validating Required Form
Fields Inline”. However, I don’t get any royalties from the book sales so this recommendation is an honest review of the book. I really think it’s that good.
Congrats to Sami Korjus and my cousin Jussi Syrjä for securing a spot for their short film Harvest Time at the Sundance Festival. I’ve seen the film now twice, in its premiere in the Tampere Film Festival last year (where it won the special prize) and last week on the national tv, and the mojo hasn’t worn off. It was one of the few movies in the festival shot on real 35mm film and the same quality can be seen throughout the whole film. If you’re into black comedies and heading to Sundance, I heartily recommend giving it a shot.
It’s annoying enough that quite a few spam messages creep through Google Groups filters to the many mailing lists I’m subscribed to. Fortunately, SpamSieve has learned to bash them quite effectively. Today, however, spam on Rails-Core and Rails-Spinoffs hit the new low (right in there with people advertising pirate copies of the first AWDWR book on the Rails mailing lists a while back).
A company apparently specialized (among many other technologies, oh the irony) in Ruby on Rails development and outsourcing, iTechArt, considered it appropriate to advertise their services by spamming pretty much every Ruby and Rails-related mailing list on Google Groups. I not only think it’s pretty darn stupid to crap in your own cubicle (so to speak), I also think it’s worth giving them a lesson. So anyone considering outsourcing or buying Ruby or Rails development, please:
Do not hire iTechArt.
If you receive a proposal from them, let them know you won’t hire spammers.
In any case, if you’re a blogger, please spread the word. iTechArt is not worth anyone’s money.
One of the most infamous student dorm houses in my hometown and whole Finland, Mikontalo, is finally put under hammer and renovated to meet the standards of the third millennium. While the construction work is underway, a bunch of TUT geeks decided to get something more out of the works:
The object of MIKONTALOLIGHTS is to create the world’s physically largest colored graphics platform by using the windows of Mikontalo’s D-staircase as light pixels. The platform is used to play Tetris and other games and present demos created by the students of Tampere University of Technology.
Here’s a video of the grand opening, including rounds of Space Invaders and Tetris (controlled with a mobile phone, of course). Times Square, beware!
My clear favorite among monospaced fonts has so far been ProFont, 9pt with no antialiasing. I don’t think antialiasing works well for small type and I have yet to see as clear and crisp a font as ProFont. However… this is what a terminal window looks like after I updated to Leopard:
Not cool. Here’s exactly the same window after switching the font to Bitstream Vera Sans Mono:
Also not cool because of the ugliness but at least all the characters are shown. Anyone got an idea what’s happening with ProFont? Everything worked just pristine in Terminal in Tiger, and still does if I run iTerm.
[UPDATE, Dec 3 2007]
I played around with the different ProFont distributions a bit, and the only one that doesn’t break as above is the bitmap ATM version of the font. However, as you can see it’s just plain ugly with small text size (notice the pixelated k, : and ~).
My friend Martin just posted a case study on Working With Rails about how Oakley has been migrating their web presence onto Rails. I’m a big fan of Oakley products. They’re a company that puts an enormous effort to make seemingly simple products better and better. In orienteering, where you really need some shield for your eyes (unlike in, say, pole vault), glasses with replaceable lenses with different colors for different weather conditions are a must. I’ve been using the M Frames for a couple of seasons, and refill my lens stock pretty much every time I visit US.
Martin’s interview with Ken Loh – the guy running the web group at Oakley – reveals an interesting point. The guys who actually build their apps got to choose the platform themselves. This is not too surprising for an innovative company such as Oakley, but it does show a clear contrast to the big E word, something Khoi Vinh and Jason Fried have lately talked about:
The people who buy enterprise software aren’t the people who use enterprise software. That’s where the disconnect begins. And it pulls and pulls and pulls until the user experience is split from the buying experience so severely that the software vendors are building for the buyers, not the users. The experience takes a back seat to the feature list, future promises, and buzz words.
In a Computerworld article telling about Steve Jobs and Apple fighting iPhone unlocking (emphasis mine):
Carolina Milanesi, a Gartner Inc. analyst who was at the London presentation, said she wondered if it matters much in the long run whether Apple stays a step ahead of hackers, as Jobs said it must do. “At the moment, as a consumer, you need to be very careful about unlocking the iPhone, and know how you want to use it,” she said. “If you unlock it, you are not going to have a flat rate, and you will not have access to the 7,500 hot spots.”
Huh? A 384Kbps (much more than iPhone can handle) flat rate plan runs around €10/month in Finland. And you have access to each and every wifi hotspot in the world with iPhone.
“If you unlock and then use the Internet and e-mail, you may be surprised by your first bill,” she added, referring to the pay-as-you-go data rates charged by most carriers in the country and elsewhere in Europe.
What the fsck does that have to do with iPhone? You pay what and how you pay regardless of the phone. You probably know what your existing contract charges for data if you’re contemplating buying and unlocking an iPhone.
The arrival to the second installment of RailsConf Europe – this time in Berlin – meant even more for me than hanging around with friends from all over the world. It also meant the first time I was able to hold an iPhone in my own hands.
See, about the same time people in US got their hands on the first iPhones, I also got a new phone, a Nokia E90 Communicator. The situation in Finland with the Communicators was almost the same as the one in US with iPhones, it was almost impossible to get one. I was lucky enough to get one in about a week, as a part of a 24-month contract. Here’s the first-quarter report about my experiences.
First things first. E90 is a pretty impressive device. With full keyboard, Wifi, 3.5G, GPS and dual screens (of which the larger one is really good) there’s hardly anything more you could hope. But that’s just on paper. Much more important to me is how useful the phone is in day-to-day use.
The browser (which uses webkit) is fairly good, certainly one of the best in the mobile world. However, the lack of a “real” mouse makes some things really hard, one of the most annoying being the fact that you can’t scroll an iframe or a div with overflow: scroll. There is no notion of dragging.
One of the most disappointing aspects is the general coherence of Symbian, which unfortunately came as no surprise. Used to OS X, I just don’t find Symbian stable or slick enough. One example of that is the selection of a Wifi network. In theory, you click the web button, select a Wifi or 3G network and continue to the browser. In practice, about half the time you just end up back to the desktop after selecting the network.
A thing that I was really disappointed by was the GPS. I’m not quite sure if it’s just my device or if it’s a “feature”, but it just takes too long for the device to find itself on the map and there’s no real feedback on what’s happening. All the UI says is that there’s no GPS available, even though in reality it’s negotiating with the satellites all the time. If you’re moving at the same time, the phone won’t ever be able to locate itself. Therefore, the GPS function has so far been totally useless for me.
Now that I got to use an iPhone in real life, I can say the two UI’s are like from different planets. It’s nice to hear that Nokia and others are coming out with touch screen phones, but I wonder if they ever get it when it comes to usability. Symbian in E90 doesn’t really reassure me in that regard.
Would I swap my omnipotent Nokia for a device using years-old phone technology? In a heartbeat. While the E90 is really nice and all, it’s an epitome of feature list competition where the more buzzwords your feature list contains, the better your phone is. And while getting 3.5G speeds is really cool, the coverage is still so bad around Finland that just having Edge for a while (until the 3G iPhone comes out) wouldn’t be too bad.
It kind of hurts me to say this as a Finn, but at the moment it seems that a newcomer in the mobile phone market has beaten the current leader pretty badly. For the customer and the market in general, that’s all but certainly a good thing.
We’re using Globalize for our latest Rails project and I just ran against a problem when running specs with rake.
We specify the base language and the locales our app supports in environment.rb:
include Globalize
Locale.set_base_language('en-US')
SupportedLocales.define(['fi-FI', 'sv-SE', 'en-US'], 'en-US')
However, SupportedLocales.define expects that the language and country data exists in the database, otherwise it will die miserably. Of course, when you run specs with rake, it will wipe the database as its first action so you’re pretty much out of luck:
.../vendor/plugins/globalize/lib/globalize/localization/supported_locales.rb:282:in `setup': Globalize base language undefined! (RuntimeError)
I fixed this by copying the db:test:clone rake task from [RAILS]/railties/lib/tasks/databases.rake to its own file in lib/tasks and modifying it so that it will load some language and country fixtures automatically:
require(File.join(RAILS_ROOT, 'vendor', 'rails', 'activerecord', 'lib', 'active_record', 'fixtures'))
namespace :db do
namespace :test do
desc "Recreate the test database from the current environment's database schema"
task :clone => %w(db:schema:dump db:test:purge) do
ActiveRecord::Base.establish_connection(ActiveRecord::Base.configurations['test'])
ActiveRecord::Schema.verbose = false
Rake::Task["db:schema:load"].invoke
Fixtures.create_fixtures("#{RAILS_ROOT}/spec/fixtures", [:globalize_countries, :globalize_languages])
end
end
end
The only thing differing from the original task is the last line creating the fixtures. For some reasons I also need to explicitly require the fixtures file on the top of the file. Aside from this, I needed to change Rakefile in the root of our Rails app to require config/environment.rb instead of config/boot.rb for everything to work.
Of course your fixture files need to include all the languages and countries you’re specifying in your SupportedLocales.define call.
After these modifications, rake runs through fine again.
It seems that my wee hometown is getting a citizen wireless network (only in Finnish, unfortunately), based on sharing your own wifi and getting free access to the network using other people’s access points in exchange. Pretty cool, especially since it’s opening already this month and I didn’t even know about it.
In the first part of this series, we had a look at how we have evolved from using the standard Rails Javascript helpers to first use the UJS for Rails plugin and then to use Low Pro on its own.
However, there’s not much documentation about Low Pro yet. In this article, we’ll introduce Low Pro to you by taking a heavily Ajax-driven, fairly inaccessible Rails page and transforming it to an accessible, unobtrusive one.
<%= link_to_function "Add new item", "$('add_form').toggle()" %>
<% remote_form_for :item, @new_item, :url => items_path,
:html => {:id => "add_form", :style => "display: none;"} do |f| %>
New item:
<%= f.text_field :description %>
<% end %>
We’ll take a closer look at the partials later, but let’s begin with the lower part of the page. There are two kinds of Rails JS helpers used. First, the link_to_function to implement toggling the visibility of the form for adding new items, and second, the remote_form_for for the actual form.
Above, the anchor tag is both inaccessible and obtrusive. Without Javascript support, nothing happens when you click the resulting link. The Javascript behaviour is also placed right into the tag.
The form tag has a normal action attribute, so it’s perfectly accessible, as long as the backend supports receiving the form submit without XmlHttpRequest. However, the tag is at least as obtrusive as the link, having the whole Ajax.Request call in the onsubmit event handler.
Let’s now make the parts accessible, starting with the link. First of all, we’ll want to make sure the link works even without Javascript. For that, we’ll modify the helper call to just use the normal link_to.
<%= link_to "Add new item", new_item_path %>
If we now click the link, it will bring us… nowhere. We don’t have a new action in our controller. Let’s create a template (new.rhtml) for it real quick. We don’t even need to add the action to the controller:
<%= render :partial => "form" %>
We already have the form in the index template, so let’s move it to the partial (_form.rhtml) from there…
<% remote_form_for :item, @new_item, :url => items_path, :html => {:id => "add_form", :style => "display: none;"} do |f| %>
New item:
<%= f.text_field :description %>
<% end %>
...and replace it in index.rhtml with a similar render call we just added to new.rhtml.
If we now click the link again, we get to the new page and see…still nothing. It’s because the form is invisible. We don’t want that, so let’s remove the style attribute from the form partial. We also don’t want the form to be a remote form by default anymore, it wouldn’t work well within the separate new page:
<% form_for :item, @new_item, :url => items_path, :html => {:id => "add_form"} do |f| %>
New item:
<%= f.text_field :description %>
<% end %>
We can try to create a new item now but we’ll get some weird stuff back. Our create action only has an RJS template so far. Let’s change the create action in items_controller.rb a bit so that it redirects in case of normal http request:
respond_to do |wants|
wants.html do
redirect_to items_path
end
wants.js
end
Now creating new items from the new action should work fine.
Progressive Enhancement
We have now ensured that adding items works without Javascript and can thus start the progressive enhancement phase. For it, we need the Low Pro javascript library.
Check the code out somewhere on your hard drive:
svn co http://svn.danwebb.net/external/lowpro/trunk lowpro
And copy the dist/lowpro.js and the behaviours subfolder to your app folder
cp dist/lowpro.js behaviours/*.js [path to your app]/public/javascripts/
We also need a way to pass certain javascript includes for specific pages. We can do this by using the content_for mechanism in Rails. Put the following into the head of your layout template:
<%= yield :javascript %>
Then add the following to your index.rhtml template
<% content_for :javascript do %>
<%= javascript_include_tag "items_index" %>
<% end %>
This makes the index action to load the Javascript file that is particular to it:
Now create the items_index.js file in your app’s public/javascripts folder and we’re ready to roll!
We’re using the excellent Event.addBehaviour method in Low Pro to attach behaviours to elements on our page. First of all, we want the form to be hidden when the page loads (remember we removed the css attribute from the element a few lines ago). This makes sure that users who have CSS working but Javascript not can still see the form.
Here, we target the form element by its id and then attach a function to it hiding the form. Note that addBehaviour always passes the actual element to the function as this, so it’s easy to call methods for that element directly.
Next, we want to make clicking the “Add new item” link to show the form. We need to first add an id to the link and then attach a behaviour to its click event.
<%= link_to "Add new item", new_item_path, :id => "add_new_link" %>
Note how the actual event is separated by a colon from the element id reference. The same way works for all Javascript events, such as submit, focus and blur.
We must remember to make the attached function return false in the end, otherwise browsers will follow through the link (just like would happen if the code was inside an onclick inline event handler).
Ok, our link is now both accessible and unobtrusive. For Javascipt-handicapped it works as a normal link, and for the majority of the users it shows the form inline on the current page.
Next thing to do is to make the form Ajax’ed again by Hijacking it, in Jeremy Keith’s terms.
Hold it! What’s that? We’re not attaching a function to the element anymore. Remote.Form is a Low Pro behaviour class, a fairly recent addition in the library. Behaviour classes can be used to encapsulate common behaviour that you would put into an attached function inside addBehaviour. Remote.Form and Remote.Link are good examples of behaviour that is pretty much the same all the time. They will automatically hijack a form or link respectively, and make them use Ajax. We could specify a bunch of attributes to the calls, but most of the time they just work, getting all the needed info from the actual form and a elements.
However, we now have one problem. Since we’re attaching another behaviour to #add_form already, the latter will override the first one and the form is not hidden on the page. We could overcome this by writing our own behaviour class. However, we will take a short cut here and hide the form when the body is loaded, instead:
Ta-da! Our link and form now work just like they did in the beginning. However, now the code works even when JS is turned off. The produced HTML now looks like this:
This is a good time to have a short break and digest what you’ve learned so far. In the next installment, we’ll tackle the select box lists of todo items and see how you can unobtrusively attach behaviours to multiple elements with very small amount of code.
In a recent Ruby on Rails podcast interview, Dan Webb stated he’d rather see the Javascript and Ajax helpers removed from the Rails core. What was the reason a prominent Rails figure like Dan holds such a radical view on the helpers?
When Rails was young and only gaining popularity, its ability to help in quickly building Ajax-equipped web applications was one of the biggest selling points for the framework. In this, helpers such as link_to_remote and remote_form_tag played a big role. However, there are two problems looming with the Rails helpers. While the helpers did manage to make writing Ajax applications as easy as not to, they also made it very easy to fall into the two major culprits of Javascript development: writing inaccessible web applications and obtrusive JS code.
Accessibility
Accessibility in the scope of Javascript can be capped with a single sentence: Can users use the web page if Javascript is not working in their browser? For the longest amount of time, Javascript was considered synonymous to inaccessible web sites. It took a lot of evangelizing (including a book by Jeremy Keith) to convince people that peppering your pages with Javascript doesn’t inherently mean they’re inaccessible.
The technique to create sites that worked both with and without Javascript was originally called graceful degradation. The page would degrade gracefully to a less advanced one if Javascript wasn’t enabled in the browser. However, people weren’t happy with the success of graceful degradation in the larger web design circles. Therefore the strategy was basically reversed and the newcomer was labeled Progressive enhancement. The idea behind progressive enhancement is that you first build the basic functionality of the page that is available to all users, and only after that build more advanced features on that foundation.
Code produced by Rails Javascript helpers isn’t necessarily inaccessible. remote_form_tag sets the action of the form tag to the same url as the target of the Ajax call, so even if the browser doesn’t support Javascript, the form should work fine:
Even link_to_remote and link_to_function give you the option to specify the href attribute manually and thus make the link accessible:
<%= link_to_function "Add new item",
"$('add_form').toggle()", :href => "/foo" %>
However, the problem is that by default the href attribute is set to ”#” (which leads nowhere), which provides an easy way to the developer to cut corners and leave the Javascript-disabled out in the cold:
<%= link_to_function "Add new item",
"$('add_form').toggle()" %>
Not surprisingly, many if not most Rails developers take the easy way out and just go with the default.
Obtrusiveness
Web evangelists have for long touted the wonders of separating the structure and presentation of web pages by using semantic HTML for structure and CSS stylesheets for styling the presentation. There is, however, a third part belonging to that separation equation, the behaviour. Behaviour is what Javascript is taking care of in web sites.
The separation of concerns is nothing new in the software world, and is fairly far even in the case of CSS. However, many still cobble their HTML views up with smaller or (more often) larger chunks of Javascript. This kind of Javascript usage is called obtrusive.
In unobtrusive Javascript, the HTML view should be left clean of Javascript. Instead, the elements are given id and class attributes that can then be used in separate Javascript files to attach behaviour to the elements. Consider the following bit of code:
This not only makes the code cleaner and puts the behaviour code where it should be, it also makes it a lot more natural to begin by making the pure-HTML version work before starting to attach behaviours to it.
The path to enlightenment
Ever since the beginning of Ajax support in Rails, people wanted a way to make their apps more accessible (read the comments in my post Using Rails AJAX helpers to create safe state-changing links for discussion about making the href attribute default to the url given to link_to_remote) and unobtrusive.
It modified the Rails Ajax helpers so that they won’t just add inline event handlers to the HTML code but instead add a dom id to the element (if one didn’t already exist) and attach an event to the element in an external Javascript file that is created and cached on the fly.
It added a helper called apply_behaviour that you could use to attach behaviour to elements by hand, using either pure Javascript or the domain-specific Ruby language familiar from the RJS templates. The helper used a CSS3 selector-like syntax (also familiar from the $$ prototype method and assert_select Rails test assertion) to select to which elements certain behaviours should be attached.
<% apply_behaviour "#add_item_link:click", "alert('Foo clicked!')" %>
<% apply_behaviour "#another_link:click" do |page|
page.alert "Ah, you clicked me again"
end %>
It added a couple of helpers to be used with apply_behaviour to call the most common prototype and script.aculo.us effects:
Under the hood of the plugin was Dan’s Low Pro Javascript library, a light set of Javascript that makes it easier to produce accessible and unobtrusive Javascript using prototype and script.aculo.us. Low Pro introduced a few additions to the prototype element accessor methods (many of which have later been brought into prototype itself), a DOM builder, and, most important, event handling code that include declarative behaviours:
As you can see, the first part of the elements in the array is the same kind of selector used in apply_behaviour—actually apply_behaviour builds this kind of Javascript calls from the Ruby code it receives. After the colon you specify either a function to be called upon the event or a behaviour class to be used (we will talk more about them in part 2). With addBehaviour, you “hijack” the basic functionality of the page and spice it with more advanced behaviour that wouldn’t be possible without Javascript.
While UJS was (and still is) a great step forward in making Javascript in Rails apps more unobtrusive – we still use it heavily on dotherightthing.com – it also has it problems. My biggest gripe with it is that while the produced HTML is clean of any Javascript, the apply_behaviour calls were still in the view code, polluting the RHTML views I was looking at days in days out. In June Dan posted a blog article titled The State (And Future) Of The UJS Plugin. In the article he writes that he’s lately not used the plugin at all and that he’s found it much better to just use Low Pro on its own without the Ruby scaffolding:
Essentially, the status is that, of late, I personally have not used UJS at all and have found a much better process by using Low Pro on its own without all the Ruby scaffolding of the UJS plugin. Secondarily, after talking to lots of developers at RailsConf it seems that the UJS plugin has failed to truly achieve it’s main goal which is to get Rails developers to write JavaScript using progressive enhancement. Many people seem to mainly use the plugin to get their JavaScript in to a separate file which is actually not even essential to progressive enhancement and I think this is a failing in the design of UJS itself. To achieve progressive enhancement you really need to think of JavaScript as a separate layer on top of a working HTML application but UJS lets you get away with keeping behavior in your views and hence leads many developers to think in the same way as they did before but think they are unobtrusive because they don’t see any JavaScript in their HTML – which is obviously not what we wanted to achieve. While many people can and do successfully use UJS for progressive enhancement even more seem not to – UJS has not been the ‘angel on your shoulder’ that I originally wanted it to be.
That single paragraph pretty much sums up my thoughts as well. And as many other people noted in the comments of the article that they, too, were mostly using just plain Low Pro instead of the plugin, I decided to give it a serious go as well. So for a recent project (a heavily Ajax-driven system) I just started writing everything without Javascript at first and then using Low Pro to progressively enhance the user experience with Ajax and other Javascript behaviours. Guess what – it’s worked wonderfully. I’m inclined to say I will never use a Rails Javascript or Ajax helper anymore. It was always more work to make them accessible than to just start with the barebones functionality and add the Javascript with Low Pro afterwards.
One initial fear I had was about dynamic serverside data that I could use with the UJS plugin. But that turned out not to be a problem at all. The cool thing about the Low Pro behaviours is that they have access to all the data on the page (even after updated by Ajax). That means you can use element id and class attribute values and the actual dynamic element content to your heart’s content. And if you really need to pass something special to the JS script alone, you can always set response headers that are then read by the Javascript code.
That’s it for part 1. Next week, in part 2, we’ll dissect an Ajax-driven, fairly inaccesible Rails page, and see how we can easily make it both accessible and unobtrusive with a few simple steps. Stay tuned!
