At the Forge - Ruby on Rails 3

What's new in Ruby on Rails 3, and what has stayed the same? Reuven explores the latest version of this framework and what it means for you.
Little Changes

That said, a bunch of little changes will become obvious almost immediately upon starting to work with Rails 3. For starters, Rails no longer has a bunch of different commands in the script directory. Instead, you use the global rails command with a parameter indicating what you want to do. So, to create a new Rails application, you use rails new appname. But, to enter the console, you say rails console or, as a gesture to slow typists, rails c. Similarly, you can use rails generate to create a new controller, model, resource or scaffold (among other things). And, you can use rails dbconsole to open a client connection to the database defined in the current environment.

I must admit, I never had a problem with the old programs in the script directory. At the same time, this means your Rails application directory can be largely empty, because the scripts instead will come from the global Rails installation.

One small but significant change is the way values are displayed in views. In previous versions of Rails, the (default) ERb templating system allowed you to insert values into the resulting HTML as follows:


<h1>Welcome back, <%= current_user.name -%>!</h1>

The <% %> brackets indicated that Ruby code should be evaluated, and the <%= %> brackets told Rails to insert the resulting value of that evaluation into the rendered HTML. The problem with this approach was that users potentially could enter not only text, but also <script> tags and JavaScript when they registered, leading to everything from annoyances to XSS (cross-site scripting) attacks.

In Rails 2, the solution was to use the “h” helper method, which turned potentially malicious tags and JavaScript into static text. This meant developers interested in removing XSS attacks had to use the “h” method in every set of <%= %> brackets that might contain user-generated input.

Rails 3 has reversed this default. Now, all strings are sanitized and defanged before they are displayed to the user. If you want to allow HTML tags (and potentially JavaScript) to be displayed, you need to use the “raw” helper method, which does the reverse of what “h” used to do:


<h1>Welcome back, <%= raw current_user.name -%>!</h1>

Another change, but a bit more substantial, is the switch away from inline JavaScript from such helpers as remote_form_for. Instead, Rails sets attributes on the HTML tag; these attributes then can be used by callback functions to invoke JavaScript. The move to unobtrusive JavaScript is a welcome one, and it will go a long way toward uncluttering views with unnecessary JavaScript code.

Active Record

The jewel in the Rails crown continues to be Active Record, an ORM that allows you to think and code with objects, while knowing (somewhere in the back of your mind) that each object instance is being stored to and retrieved from a relational database table.

The biggest change in Active Record is in the syntax you use to specify queries. In Rails 2, you would write something like this:

@people = Person.all(:conditions => "created_at > '2010-jul-14'",
       :order => "last_name ASC, first_name ASC",
       :limit => 10)

Rails 3 introduces “Active Relation”, a library used by Active Record, which changes the way you structure these queries. On the surface, the changes might seem annoying and petty. You would rewrite the above query as:

@people = Person.where("created_at => '2010-jul-14'")
               .order("last_name ASC, first_name ASC")
               .limit(10)
               .all

The first thing you'll notice is that the query has been broken up into several methods. The second thing you'll notice is that the .all call comes at the end. This is because until you invoke .all, nothing is executed in the database. This means you can mix and match method calls, adding additional conditions and complexity to your queries, until you finally decide to invoke it. So, you can build up a query over time, pass it as a parameter to a method, return it from a method or add to it conditionally—all before invoking the query on the database.

Aside from this, Active Record seems (again, on the outside) not to have changed very much. Validations now can be invoked with a slightly different syntax, foregrounding the name of the attribute you want to validate, rather than the validation itself. So instead of saying this:

validates_presence_of :email
validates_uniqueness_of :email

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix