Our Blog
TWG Talks
Business and Tech
Active state for link_to == active_link_to. A solution for building navigation systems in Rails.
I have a question for you. How do you deal with the logic of setting links as active in your navs?
Actually, I don’t want to know. It’s probably awful. I might have a pretty good solution for you. Let’s take a look at a very simple nav. These examples all use HAML:
%li= link_to 'Home', home_path
%li= link_to 'Puppies', puppies_path
%li= link_to 'Kittens', kittens_path
%li= link_to 'Froggies', froggies_path
Right, that’s great. But how do I insert logic as to what link gets marked as active? To begin, let’s quickly install this random gem:
And then change our nav a bit:
%li= active_link_to 'Home', home_path
%li= active_link_to 'Puppies', puppies_path
%li= active_link_to 'Kittens', kittens_path
%li= active_link_to 'Froggies', froggies_path
And that’s pretty much it.
So, for example, if you navigate to /kittens/1-my-fluffy-kitten navigation link for ‘Kittens’ will have ‘active’ class attached to it. It’s almost like magic.
You probably noticed that ‘Home’ is highlighted as well. It happened because whatever URL you are currently on is a child of the home_path. I guess we want to mark it as active only if we find ourselves on the home page and not anywhere else. We can fix this:
%li= active_link_to 'Home', home_path, :active => {:when => :self_only}
%li= active_link_to 'Puppies', puppies_path
%li= active_link_to 'Kittens', kittens_path
%li= active_link_to 'Froggies', froggies_path
Hey, wanna render a sub nav when you find yourself browsing /puppies or any page under that URL? It’s just sooo easy:
%li= active_link_to 'Home', home_path, :active => {:when => :self_only}
%li
= active_link_to 'Puppies', puppies_path
- if is_active_link?(puppies_path)
%ul
%li= active_link_to 'Big', big_puppies_path
%li= active_link_to 'Small', small_puppies_path
%li= active_link_to 'Kittens', kittens_path
%li= active_link_to 'Froggies', froggies_path
And that’s the skinny of what active_link_to is for.
For more documentation on more functionality checkout project on GitHub: http://github.com/theworkinggroup/active_link_to
- Add Comment
- No Comments »
- Filed under: Tech
Livin’ on the edge: Ruby, Rails, and Snow Leopard
Snow Leopard is out and I like having the latest and greatest, so I bought a new hard drive and clean installed Snow Leopard on it. This meant that I had the opportunity to reinstall my development environment with the benefit of a few years of experience and the advice of my fellow TWG’ers.
Here’s how I got my newly installed Snow Leopard up to speed for Rails development.

Ruby 1.9.1
First, I got Ruby up to date. Snow Leopard comes with Ruby 1.8.7 by default. There are many benefits to going with Ruby 1.9.1, so I went with that.
I wasn’t 100% ready to commit to Ruby 1.9.1, so I used rvm to manage my Ruby interpreters. Many gems aren’t ready for 1.9 prime-time, so I wanted the ability to drop back to Ruby 1.8 if this blew up in my face. For an overview of what is working under Ruby 1.9, check out isitruby19.com.
I installed rvm with:
rvm-install
Check out the rvm site for more information. There’s some great documentation there.
Next, I ran
to see all my installed Ruby interpreters. When you do this, you’ll see that the only Ruby installed is the system Ruby 1.8.7.
I ran ruby -v to see which Ruby was being used by default. I saw that I was using Ruby 1.8.7:
rvm will happily install and activate any version of Ruby you want.
I got it to install Ruby 1.9.1 with the following:
rvm will check to see if 1.9.1 is installed and, if it isn’t, it will download and install it for you. Once that is done, I ran rvm list again and now saw Ruby 1.9.1 listed as well as Snow Leopard system Ruby.
After that was complete, I ran rvm 1.9.1, and then ruby -v and saw that it worked:
But, I wanted Ruby 1.9.1 to be the default on my system. I got rvm to set that default by executing:
Now, the system is set to use Ruby 1.9.1 by default.
Side note: one of the neat features of rvm is that it can change your Ruby interpreter on-the-fly for you. This change isn’t permanent and only lasts for as long your Terminal session is open. For example, you can open one Terminal, execute ‘rvm system’, and have that Terminal use the Snow Leopard Ruby 1.8.7 while another one is running Ruby 1.9.1. This is very handy for compatibility testing.
MySQL
The next piece of the puzzle was MySQL. I have found that the best way to install packages like MySQL is via MacPorts.
If you haven’t done it yet, install MacPorts from here. There’s a package for Snow Leopard, so be sure to select that one.
The MacPorts MySQL package is called mysql5-server-devel, so I installed that:
MacPorts will handle all the dependencies and then install MySQL. I followed all the post-install steps that the installer recommended – start-up items, etc. The MySQL it installed is 64-bit, as it should be.
I then had to connect Ruby with MySQL and I needed the gem for that. To properly install the gem, I had to specify the architecture and the location of the mysql_config5 utility. The arch setting ensured that I got a 64-bit gem to go along with my new 64-bit MySQL installation.
Ruby Gems
I then ran gem list to see what gems I had installed. If you do this, you’ll see what I saw: not much. This makes a lot of sense because gems are installed relative to the version of Ruby they were installed with. So, all the gems that Snow Leopard had installed for Ruby 1.8.7 are no longer around for use. It was at this point that I was happy I used rvm. I dropped back to 1.8.7, got the list of installed gems and proceeded to re-install them under Ruby 1.9. But, dear reader, you don’t need to do this! Here’s how to get back to the default Snow Leopard gems under Ruby 1.9:
This’ll take a while. Go grab a coffee. Run around the block. Do something fun.
If any of these fail for you, check out isitruby19.com for tips on how to get it working.
Passenger
The next piece I needed was Passenger aka mod_rails. I needed version 2.2.5 (newest as of writing) for this to all work together. I installed it with:
This retrieved and compiled Passenger 2.2.5 for me. It might get a newer version for you. Once that completed, I ran:
The Passenger module depends on your current Ruby version, so you have to re-compile Passenger if you change your Ruby version. It is important that the Passenger compilation properly links with the Ruby interpreter you want to use. In this case, that’s Ruby 1.9.1.
When you do this the Passenger installation, double-check the paths that the Passenger compilation process outputs and ensure that it is properly finding the Ruby 1.9.1 installed in your .rvm directory. If you see paths that don’t go to .rvm in your home directory, then it is doing it wrong. If this happens, ensure that rvm is set to use 1.9.1 by default and try again.
Next, I edited my httpd.conf just as the Passenger installer recommended. I opened it up with open /etc/apache2/httpd.conf and pasted in the Passenger lines.
The Passenger Preference Pane makes everything easier, so definitely wanted that.
I got lucky and found that it had just been updated to support Snow Leopard, so make sure you get version 1.3 or greater.
Taa daa!
That’s it!
Set up a Rails project in the Passenger Preference Pane and try it out! You should see your fully functional Rails app running.
- Add Comment
- 19 Comments »
- Filed under: Tech