"Ruby on Rails" comprehensively renovated

Following two release candidates, the official version 2.3 of the open source Ruby on Rails web framework has now been released. Although David Heinemeier Hansson, creator of Rails, had originally said in 2007 that there would now only be evolutionary changes in Rails, version 2.2, with its introduction of i18n API, multithreading and experimental support for Ruby 1.9, was a comprehensive release and now version 2.3 introduces further substantial changes.

One of the major changes is hidden under the bonnet: the now elderly CGI library in the Rails core has been replaced with Rack, a minimal interface for connecting web servers and web frameworks. It uses ideas from the Web Server Gateway Interface of the Python programming language. One benefit of using Rack is that many middleware pieces are already available for virtually any web or application server in the Ruby world (including the Apache mod_passenger module), so developers of these servers for Rails won't have to develop their own solutions. Another is the interesting ecosystem of other web frameworks and middleware solutions now evolving around Rack that can take over tasks such as caching and file compression. Rack also enables different web applications and middleware to be used at the same time by means of simple configurations, for example allowing this or that web framework to be accessed, depending on its URL. Systematic rearrangement of the Rails internals to form Rack mechanisms now also lets these frameworks exchange session data.

The developers have also revised other parts of Rails. ActiveRecord has finally been given nested model assignments, although the function was originally announced for Rails 2.2. With these, data for linked objects can be directly assigned with a simple syntax and corresponding objects can be created. A number of database transactions can now be similarly nested, a feature that many developers have had on their wish list for a long time.

There are more changes to the named scopes that were introduced with Rails 2.1: they can now also be created dynamically. In addition, a default scope can be specified for a model to allow tasks to be run such as a prescribed sort or the virtual deletion of objects. The last change worth mentioning in ActiveRecord is that it permits iteration over objects in subdivided packets, which makes the batch processing of large tables more efficient.

In the Controller and View domain, there are a few changes to the i18n API. For example, localized Views can now be created that contain the name of the locale in the file name, which is helpful with particularly text-heavy Views. One major change is a great simplification of the syntax for render, so that only the most essential parameters usually have to be passed for rendering either templates or partials. Support for HTTP digest authentication has been added.

Routeing has become much more efficient in Rails 2.3, but the formatted_ routes that were automatically generated for REST routes have gone, so the syntax for creating links to resources with other content types has changed slightly. For the first time, Rails 2.3 also officially supports Rails Engines, encapsulated Rails applications that can be embedded within other applications.

In the ActiveSupport area, the introduction of Object#try is particularly worthy of mention. As the name suggests, you can use it to try calling a method on an object. If this method doesn't exist (for example because the object has the wrong type, because it's nil, nil will be returned instead of an exception being raised. This can, for example, make Views more error-tolerant.

Likewise, support for application templates is new: a basic template can be defined for an application that will then automatically be used when the application is generated. That can mean installing plug-ins, declaring gem dependencies, calling up generators, or running shell commands. It also permits shortening the setup time for new applications. A whole range of templates for various purposes can already be found on GitHub, and there is a generator for more templates at Railsboost that can be configured with a few clicks.

The influence of the Merb team on Rails development is already clearly noticeable in this version – the two projects announced their merger in late December. It will be interesting to see how many Merb ideas will be incorporated into Rails 3, and whether the Rails team will manage to keep the modularisation that will probably accompany it, largely transparent for the typical Rails developer.

(Jan Krutisch)

(crve)