too lazy for blogging

I must have missed the part of the changelog where it states that the errors.add_to_base call will be deprecated. Anyhow, I searched the web and almost every case refers to the new API using

errors[:base] = 'My error message'

or 

errors[:base] << 'My error message'

This might be fine for single language apps, but when you have to provide the interface in many languages and want to keep all your error messages in one language file, you would have to replace ‘My error message’ with a call like

errors[:base] << I18n.t('activerecord.errors.models.model_name.attributes.base.my_code')

Another method which I could not really find in any blog post out there is a simple

errors.add(:base, :my_code)

Far shorter and it gets automatically namespaced. So have fun ;)

In case you are using a combination of Authlogic, Cucumber and the CookieSessionStore, be very careful with your domain configuration. As our project is working with various subdomains, we are using /etc/hosts with an .local extension on our dev machines. But be careful with the settings. In rails3 you are not supposed to set the session store in the environment config files, but in an initializer. If you are not careful and define a domain for cucumber, you might get into trouble, as it uses www.example.com internally. And all the cookies you are setting are invalid.

I should have thought about it earlier, but at least I found my mistake :(

As I am upgrading one of our projects to rails3 right now, I had to deal with lots of obsolete and not longer working code. And I came across this little gem I picked up from Pratik Naik. It allows you to nest your layouts pretty easily. If you upgrade to rails3 you have to change the code to:

def parent_layout(layout)
  @_content_for[:layout] = self.output_buffer
  self.output_buffer = render(:file => "layouts/#{layout}")
end

RubyOnRails does no longer use multiple instance variables to store the contents, but a single hash. 

I am wondering when and, more important, how the first larger applications will be ported to rails3. When I check my largest and most important project, I see a lot of gems and plugins which are not yet supported. For some of them there is not even the slightest note on any progress towards rails3 compatibility. I know, as a good citizen of the open source community, I should help and update them myself. But there are far too many. So I will be stuck with rails 2.3.5.

I guess I will fork and upgrade a few smaller projects as soon as there will be time again. But I wonder why the adoption path seems so slow. Or am I missing something?

Probably one of the most used RubyOnRails extensions will use the rails 3 upgrade to introduce some major internal changes as well. Just in case you have implemented your own renderer which inherits from WillPaginate::LinkRenderer, be prepared to update your code. Apart from the fact that the namespace changed to WillPaginate::ViewHelpers::LinkRenderer, the implemented methods and names changed as well.

In the one case I am working on right now, the protected page_link method has been replaced by link(text, target, attributes = {}). So if you are seeing any errors like “undefined constant WillPaginate::LinkRenderer” have a look at the source code!

The first day I managed to install the app and do some quick testing on the recently released beta. Everything seemed ok and kept working on my projects.

Three days later I started a project from scratch and directly jumped on the rails3 wagon. And I think I was instantly hooked. Man, this baby is sooooo much fun. Not only gem dependencies are finally working, but ActiveRecord with Arel is just amazing. It reminds me a lot of my .NET days ;)

And the best feature I have not yet mentioned! The speed. Everything is really fast and smooth. Running it locally in development mode is a real pleasure. Even on a dated white macbook, pages load even as if you are in production mode. Amazing.

So, why is it a pain in the ass?
Quite easy, I have to update all my projects to use rails3 in order to be able to deploy it to our production server. Passenger can handle only one rack version and while rails requires rack version 1.0.1, rails3beta requires 1.1.0 . What a pitty!

If your 2.3.5 start behaving strangely after installing rails3beta, it might be due to the I18n gem. Previous versions of rails came with an older packed version which was automatically loaded. Now with rails3 and 2.3.5 already, you can actually install the newer I18n gem yourself (and it actually gets loaded). So here is what you might wanna do:

• Update your application to work with the new I18n API (what I did)
• Require a specific older version of the gem (probably 0.2)
• Uninstall the gem (which will break your rails3beta)

I would recommend updating your applications. It was a bit of a hassle for me, but this way I can be sure to be on the right path for the future. Or who does not want to use this really beautiful new query API?

Update: Please take care the the I18n.l(input, :format => ‘identifier_string’) is not working anymore. Instead of passing a string to format you should use a symbol instead.