Jul’s blog

Getting familiar with Rails 3

With the advent of Rails 3, we have to learn a lot. We have great sources, like a free PeepCode screencast for live upgrade, not mentioning the release notes. I don’t want to rephrase the install, but some config differences which make our job easier.I took the opportunity to switch to Ruby 1.9 recently, and it seemed natural to continue to use all the old gems I used.  There are slight differences, but this assumption was more or less accurate. There are some issues with encoding, but it’s not a showstopper. However, when I wanted to run the newly installed rails or rails-update commands, I got a ton of .gemspec errors.

First issue: ruby and rubygems

Bundler is the new way to handle your gem dependencies. In the extreme it means you don’t have to have any other gem installed than bundler. On the other side, ruby 1.9 is bundled (sic!) with rubygems 1.3.1, but the latest bundler requires rubygems >= 1.3.5. As a side note, installing rails 3.0.0.beta requires rubygems 1.3.5 too, because earlier ones didn’t recognize alphabetic characters in version names. Therefore 1.3.5 is a must.

However, if you update to 1.3.5, you’ll get errors like ‘WARNING: Invalid .gemspec format in …’, and rails command will report other errors too.

If you have a look of irb, you can find the culprit:

This (…/lib/ruby/<version>/rubygems*) points to the bundled (v1.3.1) ruby, while the latest one is installed to …/lib/ruby/site-ruby/<version>/rubygems*. If you have rubygems 1.3.5 installed (gem update –system), you can remove …/lib/ruby/<version>/rubygems* by hand, and the problem is gone.

Second issue: shallow nesting

It seems rails 3.0.0.beta doesn’t have support for shallow nesting. Or at least the new native implementation doesn’t contain it. The funniest part is it seems nobody cares about it. I use shallow nesting myself, so this is a showstopper for me. Rails 3′s router lives in actionpack gem, in ActiveDispatch namespace. Nesting is done by recursive scope changes. The easiest way for manage shallowing the path is to record scope info before scoping, and remove that temporarily from the scope when shallow paths are needed.

Then, all you have to do is to save the scope in front of resources (keep the root of scope shallowing in @scope[:shallow]), and embed block and member route generation calls in ‘with_shallow_scope(saved_scope)’ calls.

Third problem, phasing out gems

I’m using cucumber, rspec, factory_girl for testing, and, most importantly, lockdown for authorization. For now rspec (especially rspec-rails) is not quite there, a lot of stuff has to be rewritten. There is a 2.0.0 alpha prerelease, but it’s really an alpha.

Factory_girl is in the same boat, while the latest github version can be configured somehow, we still miss a gem for that.

No problem, we’ll work with no tests for a while (and/or we won’t actually run the tests). However, user authorization hurts us: lockdown won’t support rails3.

While I think there’re a lot of great stuff out there, I couldn’t yet find anything which would fit my needs. So far we have a lot of great gems out there with excellent DSL’s (CanCan looks pretty neat!), however they all try to solve the problem in a wrong place.

We got a cartload of hints about using Rack for this stuff. Why don’t we? Is it really necessary to pollute all of your controllers? Haven’t you realized that the only place you have to identify authorization is just after routing? Well yes, you can specify that you should be able to do this and that, or you can allow people looking at a page, but they get different response according to their rights. I’m not even convinced that you don’t violate the REST principle by this, but it should not be a big deal adding this to the DSL.

Therefore this is my open question: how can I replace authorization in Rails3?

UPDATE: I have made some changes in shallow routing method to keep paths before shallow.

blog comments powered by Disqus