Rails 2.0 Has Been Released!

I’m certainly not the first person to put this information out there, but for anyone that has been following this blog for Rails information should be aware that the newest version has been released. Rails 2.0 boasts a series of new features and improvements, most of which appear to me to be under the hood more than right in your face. Most notable to me are the following changes and new features:

1. View template file name changes.
In order to more accurately reflect what Rails is doing, all generators will now use a new naming convention with regards to view templates. In the past a view file might be called something like “articles.rhtml”, which would denote that an HTML view is to be rendered. In an effort to separate out the MIME type and the renderer of the view, the new naming convention will use names such as “articles.html.erb”. In this example, you can see that the file name shows a MIME type of HTML, and that the ERB renderer should be used to render the output. What would previously have been “articles_rss.rxml” would now be called “articles_rss.xml.builder”, telling us that the MIME type will be XML and that Rails will use the Builder renderer to show the view. Older template file names will still work until Rails 3.0 is released, so this one is going to be a phased transition.

2. Security Enhancements to the “Sanitize” Method.
Before last week, using the “sanitize” method to try and prevent XSS attacks was not the best option in the world. Rather, most people (such as myself) opted to use the “white_list” plugin for Rails. Rather than the blacklisting of certain tags with “sanitize”, the white_list plugin worked by letting developers specify exactly which tags ARE allowed, rather than which are not. Much more secure, and with Rails 2.0 the “sanitize” method has been greatly improved. In fact, it has taken the form of a white_list, replacing that plugin. This is one of many security improvements in Rails 2.0.

3. Native Pagination is Gone.
Rails 2.0 has removed the “paginate” methods for creating multiple pages of results, opting instead to have that functionality abstracted out to a plugin. I’m not sure what I think about this one, as the native pagination methods have proven to me that they need work. However, currently I use them in conjunction with a customized pagination method to get the results that I want. My presumption here is that the available plugins will be just fine to get things done, since pagination is something that we all use.

4. Improved Control Over Representations
I’ll admit that I haven’t gotten too deep into this one, but there appear to be a lot of improvements in the area of presenting multiple views from only one action. From what I can tell, this is done using the “initializers” that Rails 2.0 offers, allowing you to define particular “MIME” types in your application. This is somewhat related to the first point above, but a little different. For example, we can now tell Rails that we want to internally define a MIME type of “iphone” and have the actual MIME type that it announces to a browser be “text/html”. We can now do that in our Rails 2.0 applications and then we can use views with file names like “articles.iphone.erb”. This let’s you have a single action that can respond in a series of formats such as “articles.html.erb”, “articles.xml.builder” and “articles.iphone.erb”. It might seem confusing, but to me this is a great improvement, and will help with organization of application code.

This entry was posted on Tuesday, December 11th, 2007 at 3:20 pm and is filed under Application Development, Ruby on Rails. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

↑ Back to Top

Brian Getting is the Online Director at Practical eCommerce, specializing in website design and application development.