CSC/ECE 517 Fall 2011/ch2 2f mm

Rails 2 vs. Rails 3

A lot changed in the update from Rails 2 to Rails 3. We will explore a few of the key areas that will affect a programmer's everyday coding.

Rails Application Scripts

When you create a new Rails application, a directory named script is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:

• generate: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
• destroy: Used to destroy code created by the generate method.
• server: Starts up the Rails application in a self-contained web server.
• plugin: Helps with the installation and administration of plug-ins to the Rails framework.
• performance directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

Rails 3 does away with all of these scripts and compiles them all into a single script named rails. With this script, the programmer can access all of the functionality that was available with the separate scripts. To make things even easier, the necessity to call this script outright is even unnecessary. By using the operating systems installed rails command (ex, /usr/bin/rails on Linux systems) in the root of any Rails 3 application, it will know to call this script.

Gem Dependencies

The ability to extend the Rails framework using a Gem is a very powerful feature. In Rails 2, the config/environment.rb file had to be edited in order to tell the Rails application to require specific Gems using the config.gem method. To ensure that the Gems were actually installed on the system running the Rails application, the programmer had to execute the rake gem:install command.

Rails 3 does away with the need to have that manual process of installing Gems by utilizing a file named Gemfile in the root of the application as well as the Bundler. The Bundler looks at the contents Gemfile and automatically installs any Gems that are missing from the system. This allows the programmer to focus on more important issues.

JavaScript Support<ref>Gadbois 2010</ref>

There are many JavaScript libraries available to programmers to make their web applications more dynamic and smooth looking. Whenever you created a Rails 2 application, it would automatically install the Prototype and Script.aculo.us frameworks. Rails also provided helpers for these two JavaScript frameworks so that a few method calls were all that you needed to make your application more fluid.

Rails 3 introduces the idea of Unobtrusive JavaScript (UJS). The JavaScript becomes unobtrusive by not being written in with the HTML objects producing cleaner code that is easier to debug. This is mostly done with the utilization of HTML 5 custom attributes such as data-method, data-confirm, data-remote and data-disable-with:

<form action="http://host.com" id="create-post" method="post" data-remote="true" data-confirm="Are you sure you want to submit?">

By doing this, it also frees Rails from being dependent on the Prototype framework, allowing it to become JavaScript framework agnostic. With its current implementation, the framework can support Prototype, jQuery and MooTools.

It might also be helpful to point out that as of Rails 3.1, the jQuery framework has replaced Prototype as the default JavaScript framework. Programmers that wish to still use Prototype must remember to specify this when they create the Rails application.

rails new myapp -j prototype

References

Citation Notes

<references/>

Full Reference Information

Ruby, Sam, Dave Thomas and David Hansson. Agile Web Development with Rails: Third Edition: The Pragmatic Programmers LLC, 2009.

Gadbois, John. Using Unobtrusive JavaScript and AJAX with Rails 3 http://net.tutsplus.com/tutorials/javascript-ajax/using-unobtrusive-javascript-and-ajax-with-rails-3/ , 2010.