Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T04:44:27Z

Hmalipa:

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework is refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier to configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

Rails 3 has undergone many changes from architectural to syntax and it’s too big to discuss all
those in a single article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating these concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
The structural changes relate to changes architecture. Many of the previously existing components have been realigned to make it better [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework. The following sections talk about changes in all the three components namely, [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Action Record], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] and also other supporting components.

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Active Record] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller],
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between Active Record, its
default ORM, and [http://ap.rubyonrails.org/ Action Pack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell Action Pack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled Action Pack from Active Record directly,
and Active Record becomes just one of many ORMs to implement the Active Model API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, Action Controller had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====Action Dispatch=====
The dispatcher functionality has been moved into Action Dispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect [http://en.wikipedia.org/wiki/Domain-specific_language DSL] still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====Abstract Controller====
Rails 3 has refactored Action Controller and Action Mailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about [http://en.wikipedia.org/wiki/HTTP HTTP] or mail delivery.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] now has Abstract Controller, a base superclass that is separated from the notions of
HTTP. This Abstract Controller handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
This section presents changes related to code generation commands like scaffold and migration commands. Many of the commands in Rails 2 have aliases in Rails 3 which are easy to remember and hence helps in reducing development phase cycle.

====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.

===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations the graph shows basic statements execution time vs Rails version]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations the graph shows complex statements execution time vs Rails version]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T04:43:01Z

Hmalipa:

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework is refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier to configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this single article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
The structural changes relate to changes architecture. Many of the previously existing components have been realigned to make it better [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework. The following sections talk about changes in all the three components namely, [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Action Record], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] and also other supporting components.

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Active Record] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller],
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between Active Record, its
default ORM, and [http://ap.rubyonrails.org/ Action Pack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell Action Pack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled Action Pack from Active Record directly,
and Active Record becomes just one of many ORMs to implement the Active Model API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, Action Controller had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====Action Dispatch=====
The dispatcher functionality has been moved into Action Dispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect [http://en.wikipedia.org/wiki/Domain-specific_language DSL] still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====Abstract Controller====
Rails 3 has refactored Action Controller and Action Mailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about [http://en.wikipedia.org/wiki/HTTP HTTP] or mail delivery.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] now has Abstract Controller, a base superclass that is separated from the notions of
HTTP. This Abstract Controller handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
This section presents changes related to code generation commands like scaffold and migration commands. Many of the commands in Rails 2 have aliases in Rails 3 which are easy to remember and hence helps in reducing development phase cycle.

====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.

===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations the graph shows basic statements execution time vs Rails version]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations the graph shows complex statements execution time vs Rails version]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T04:23:09Z

Hmalipa:

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework is refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this single article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
The structural changes relate to changes architecture. Many of the previously existing components have been realigned to make it better [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework. The following sections talk about changes in all the three components namely, [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Action Record], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] and also other supporting components.

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Active Record] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller],
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between Active Record, its
default ORM, and [http://ap.rubyonrails.org/ Action Pack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell Action Pack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled Action Pack from Active Record directly,
and Active Record becomes just one of many ORMs to implement the Active Model API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, Action Controller had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====Action Dispatch=====
The dispatcher functionality has been moved into Action Dispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect [http://en.wikipedia.org/wiki/Domain-specific_language DSL] still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====Abstract Controller====
Rails 3 has refactored Action Controller and Action Mailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about [http://en.wikipedia.org/wiki/HTTP HTTP] or mail delivery.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] now has Abstract Controller, a base superclass that is separated from the notions of
HTTP. This Abstract Controller handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
This section presents changes related to code generation commands like scaffold and migration commands. Many of the commands in Rails 2 have aliases in Rails 3 which are easy to remember and hence helps in reducing development phase cycle.

====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.

===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations the graph shows basic statements execution time vs Rails version]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations the graph shows complex statements execution time vs Rails version]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T04:21:26Z

Hmalipa:

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
The structural changes relate to changes architecture. Many of the previously existing components have been realigned to make it better [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework. The following sections talk about changes in all the three components namely, [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Action Record], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] and also other supporting components.

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Active Record] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller],
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between Active Record, its
default ORM, and [http://ap.rubyonrails.org/ Action Pack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell Action Pack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled Action Pack from Active Record directly,
and Active Record becomes just one of many ORMs to implement the Active Model API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, Action Controller had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====Action Dispatch=====
The dispatcher functionality has been moved into Action Dispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect [http://en.wikipedia.org/wiki/Domain-specific_language DSL] still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====Abstract Controller====
Rails 3 has refactored Action Controller and Action Mailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about [http://en.wikipedia.org/wiki/HTTP HTTP] or mail delivery.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] now has Abstract Controller, a base superclass that is separated from the notions of
HTTP. This Abstract Controller handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
This section presents changes related to code generation commands like scaffold and migration commands. Many of the commands in Rails 2 have aliases in Rails 3 which are easy to remember and hence helps in reducing development phase cycle.

====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.

===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations the graph shows basic statements execution time vs Rails version]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations the graph shows complex statements execution time vs Rails version]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T04:21:10Z

Hmalipa: /* Introduction */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Structural===
The structural changes relate to changes architecture. Many of the previously existing components have been realigned to make it better [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework. The following sections talk about changes in all the three components namely, [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Action Record], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] and also other supporting components.

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Active Record] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller],
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between Active Record, its
default ORM, and [http://ap.rubyonrails.org/ Action Pack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell Action Pack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled Action Pack from Active Record directly,
and Active Record becomes just one of many ORMs to implement the Active Model API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, Action Controller had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====Action Dispatch=====
The dispatcher functionality has been moved into Action Dispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect [http://en.wikipedia.org/wiki/Domain-specific_language DSL] still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====Abstract Controller====
Rails 3 has refactored Action Controller and Action Mailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about [http://en.wikipedia.org/wiki/HTTP HTTP] or mail delivery.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] now has Abstract Controller, a base superclass that is separated from the notions of
HTTP. This Abstract Controller handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
This section presents changes related to code generation commands like scaffold and migration commands. Many of the commands in Rails 2 have aliases in Rails 3 which are easy to remember and hence helps in reducing development phase cycle.

====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.

===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations the graph shows basic statements execution time vs Rails version]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations the graph shows complex statements execution time vs Rails version]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T04:19:34Z

Hmalipa: /* Active Model Abstraction */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
The structural changes relate to changes architecture. Many of the previously existing components have been realigned to make it better [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework. The following sections talk about changes in all the three components namely, [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Action Record], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] and also other supporting components.

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Active Record] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller],
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between Active Record, its
default ORM, and [http://ap.rubyonrails.org/ Action Pack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell Action Pack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled Action Pack from Active Record directly,
and Active Record becomes just one of many ORMs to implement the Active Model API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, Action Controller had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====Action Dispatch=====
The dispatcher functionality has been moved into Action Dispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect [http://en.wikipedia.org/wiki/Domain-specific_language DSL] still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====Abstract Controller====
Rails 3 has refactored Action Controller and Action Mailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about [http://en.wikipedia.org/wiki/HTTP HTTP] or mail delivery.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] now has Abstract Controller, a base superclass that is separated from the notions of
HTTP. This Abstract Controller handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
This section presents changes related to code generation commands like scaffold and migration commands. Many of the commands in Rails 2 have aliases in Rails 3 which are easy to remember and hence helps in reducing development phase cycle.

====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.

===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations the graph shows basic statements execution time vs Rails version]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations the graph shows complex statements execution time vs Rails version]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T04:18:42Z

Hmalipa:

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
The structural changes relate to changes architecture. Many of the previously existing components have been realigned to make it better [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework. The following sections talk about changes in all the three components namely, [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Action Record], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] and also other supporting components.

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Active Record] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller],
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between Active Record, its
default ORM, and [http://ap.rubyonrails.org/ Action Pack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell Action Pack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the Active Model API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, Action Controller had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====Action Dispatch=====
The dispatcher functionality has been moved into Action Dispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect [http://en.wikipedia.org/wiki/Domain-specific_language DSL] still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====Abstract Controller====
Rails 3 has refactored Action Controller and Action Mailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about [http://en.wikipedia.org/wiki/HTTP HTTP] or mail delivery.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] now has Abstract Controller, a base superclass that is separated from the notions of
HTTP. This Abstract Controller handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
This section presents changes related to code generation commands like scaffold and migration commands. Many of the commands in Rails 2 have aliases in Rails 3 which are easy to remember and hence helps in reducing development phase cycle.

====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.

===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations the graph shows basic statements execution time vs Rails version]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations the graph shows complex statements execution time vs Rails version]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T04:17:59Z

Hmalipa: /* AbstractController */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
The structural changes relate to changes architecture. Many of the previously existing components have been realigned to make it better [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework. The following sections talk about changes in all the three components namely, [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Action Record], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] and also other supporting components.

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Active Record] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller],
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between Active Record, its
default ORM, and [http://ap.rubyonrails.org/ Action Pack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell Action Pack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the Active Model API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, Action Controller had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====Action Dispatch=====
The dispatcher functionality has been moved into Action Dispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect [http://en.wikipedia.org/wiki/Domain-specific_language DSL] still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====Abstract Controller====
Rails 3 has refactored Action Controller and Action Mailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about [http://en.wikipedia.org/wiki/HTTP HTTP] or mail delivery.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] now has Abstract Controller, a base superclass that is separated from the notions of
HTTP. This Abstract Controller handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
This section presents changes related to code generation commands like scaffold and migration commands. Many of the commands in Rails 2 have aliases in Rails 3 which are easy to remember and hence helps in reducing development phase cycle.

====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.

===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations the graph shows basic statements execution time vs Rails version]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations the graph shows complex statements execution time vs Rails version]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T04:17:23Z

Hmalipa: /* ActionDispatch */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
The structural changes relate to changes architecture. Many of the previously existing components have been realigned to make it better [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework. The following sections talk about changes in all the three components namely, [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Action Record], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] and also other supporting components.

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Active Record] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller],
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between Active Record, its
default ORM, and [http://ap.rubyonrails.org/ Action Pack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell Action Pack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the Active Model API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, Action Controller had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====Action Dispatch=====
The dispatcher functionality has been moved into Action Dispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect [http://en.wikipedia.org/wiki/Domain-specific_language DSL] still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about [http://en.wikipedia.org/wiki/HTTP HTTP] or mail delivery.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] now has Abstract Controller, a base superclass that is separated from the notions of
HTTP. This Abstract Controller handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
This section presents changes related to code generation commands like scaffold and migration commands. Many of the commands in Rails 2 have aliases in Rails 3 which are easy to remember and hence helps in reducing development phase cycle.

====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.

===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations the graph shows basic statements execution time vs Rails version]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations the graph shows complex statements execution time vs Rails version]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T04:15:23Z

Hmalipa: /* Development */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
The structural changes relate to changes architecture. Many of the previously existing components have been realigned to make it better [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework. The following sections talk about changes in all the three components namely, [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Action Record], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] and also other supporting components.

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Active Record] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller],
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between Active Record, its
default ORM, and [http://ap.rubyonrails.org/ Action Pack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell Action Pack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the Active Model API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, Action Controller had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about [http://en.wikipedia.org/wiki/HTTP HTTP] or mail delivery.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] now has Abstract Controller, a base superclass that is separated from the notions of
HTTP. This Abstract Controller handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
This section presents changes related to code generation commands like scaffold and migration commands. Many of the commands in Rails 2 have aliases in Rails 3 which are easy to remember and hence helps in reducing development phase cycle.

====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.

===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations the graph shows basic statements execution time vs Rails version]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations the graph shows complex statements execution time vs Rails version]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T04:11:01Z

Hmalipa: /* AbstractController */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
The structural changes relate to changes architecture. Many of the previously existing components have been realigned to make it better [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework. The following sections talk about changes in all the three components namely, [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Action Record], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] and also other supporting components.

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Active Record] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller],
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between Active Record, its
default ORM, and [http://ap.rubyonrails.org/ Action Pack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell Action Pack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the Active Model API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, Action Controller had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about [http://en.wikipedia.org/wiki/HTTP HTTP] or mail delivery.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] now has Abstract Controller, a base superclass that is separated from the notions of
HTTP. This Abstract Controller handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations the graph shows basic statements execution time vs Rails version]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations the graph shows complex statements execution time vs Rails version]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T04:06:53Z

Hmalipa: /* Active Model Abstraction */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
The structural changes relate to changes architecture. Many of the previously existing components have been realigned to make it better [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework. The following sections talk about changes in all the three components namely, [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Action Record], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] and also other supporting components.

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Active Record] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller],
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between Active Record, its
default ORM, and [http://ap.rubyonrails.org/ Action Pack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell Action Pack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the Active Model API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, Action Controller had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
[http://en.wikipedia.org/wiki/HTTP HTTP]. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations the graph shows basic statements execution time vs Rails version]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations the graph shows complex statements execution time vs Rails version]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T04:00:01Z

Hmalipa: /* Modularization */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
The structural changes relate to changes architecture. Many of the previously existing components have been realigned to make it better [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework. The following sections talk about changes in all the three components namely, [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Action Record], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] and also other supporting components.

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Active Record] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller],
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and [http://ap.rubyonrails.org/ ActionPack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, Action Controller had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
[http://en.wikipedia.org/wiki/HTTP HTTP]. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations the graph shows basic statements execution time vs Rails version]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations the graph shows complex statements execution time vs Rails version]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T03:57:55Z

Hmalipa: /* Action Controller */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
The structural changes relate to changes architecture. Many of the previously existing components have been realigned to make it better [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework. The following sections talk about changes in all the three components namely, [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Action Record], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] and also other supporting components.

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and [http://ap.rubyonrails.org/ ActionPack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, Action Controller had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
[http://en.wikipedia.org/wiki/HTTP HTTP]. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations the graph shows basic statements execution time vs Rails version]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations the graph shows complex statements execution time vs Rails version]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T03:57:07Z

Hmalipa:

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
The structural changes relate to changes architecture. Many of the previously existing components have been realigned to make it better [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework. The following sections talk about changes in all the three components namely, [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Action Record], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Action_Controller Action Controller] and also other supporting components.

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and [http://ap.rubyonrails.org/ ActionPack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
[http://en.wikipedia.org/wiki/HTTP HTTP]. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations the graph shows basic statements execution time vs Rails version]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations the graph shows complex statements execution time vs Rails version]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T03:55:40Z

Hmalipa: /* Structural */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
The structural changes relate to changes architecture. Many of the previously existing components have been realigned to make it better [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework. The following sections talk about changes in all the three components namely, [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Action Record], Action Controller and also other supporting components.

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and [http://ap.rubyonrails.org/ ActionPack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
[http://en.wikipedia.org/wiki/HTTP HTTP]. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations the graph shows basic statements execution time vs Rails version]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations the graph shows complex statements execution time vs Rails version]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T03:53:20Z

Hmalipa:

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
The structural changes relate to changes architecture. Many of the previously existing components have been realigned to make it better [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework. The following sections talk about changes in all the three components namely, [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2f_vh#Active_Record Action Record], Action View, Action Controller and also other supporting components.

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====

Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and [http://ap.rubyonrails.org/ ActionPack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
[http://en.wikipedia.org/wiki/HTTP HTTP]. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations the graph shows basic statements execution time vs Rails version]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations the graph shows complex statements execution time vs Rails version]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T03:51:16Z

Hmalipa: /* Structural */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
The structural changes relate to changes architecture. Many of the previously existing components have been realigned to make it better [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework. The following sections talk about changes in all the three components namely, Action Record, Action View, Action Controller and also other supporting components.

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====

Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and [http://ap.rubyonrails.org/ ActionPack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
[http://en.wikipedia.org/wiki/HTTP HTTP]. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations the graph shows basic statements execution time vs Rails version]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations the graph shows complex statements execution time vs Rails version]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T03:42:47Z

Hmalipa: /* Performance */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====

Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and [http://ap.rubyonrails.org/ ActionPack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
[http://en.wikipedia.org/wiki/HTTP HTTP]. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations the graph shows basic statements execution time vs Rails version]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations the graph shows complex statements execution time vs Rails version]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T03:40:50Z

Hmalipa: /* AbstractController */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====

Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and [http://ap.rubyonrails.org/ ActionPack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
[http://en.wikipedia.org/wiki/HTTP HTTP]. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T03:30:50Z

Hmalipa: /* AbstractController */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====

Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and [http://ap.rubyonrails.org/ ActionPack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
[HTTP http://en.wikipedia.org/wiki/HTTP]. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.

===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T03:29:26Z

Hmalipa: /* Active Model Abstraction */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====

Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and [http://ap.rubyonrails.org/ ActionPack], its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>

====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T03:26:35Z

Hmalipa: /* Active Record */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====

Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a [http://en.wikipedia.org/wiki/Relational_algebra Relational Algebra] for Ruby. It simplifies the
generation complex of [http://en.wikipedia.org/wiki/SQL SQL] queries and adapts to various [http://en.wikipedia.org/wiki/RDBMS RDBMS] systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T03:23:33Z

Hmalipa: /* Modularization */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====

Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like [http://en.wikipedia.org/wiki/Datamapper DataMapper], to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires.

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T03:22:17Z

Hmalipa: /* Modularization */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====

Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework PrototypeJS] as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T03:21:22Z

Hmalipa:

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====

Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its [http://en.wikipedia.org/wiki/Object-relational_mapping ORM] layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-30T03:19:59Z

Hmalipa:

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====

Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM[http://en.wikipedia.org/wiki/Object-relational_mapping] layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T03:08:20Z

Hmalipa: /* Active Record */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====

Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..

====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T03:06:55Z

Hmalipa:

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===

Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===

====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.

====Modularization====

Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..

====Active Record====

'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>

In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T03:05:12Z

Hmalipa: /* Active Record */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===
Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>

And the following calculation methods :

<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>

Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).

Example of deprecated usage:

<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T03:04:48Z

Hmalipa: /* Active Record */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===
Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
'''Change in query interface'''

In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T03:04:36Z

Hmalipa: /* Active Record */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===
Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
'''Change in query interface'''
In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T03:03:17Z

Hmalipa:

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself (DRY)''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===
Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
Change in query interface:
In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T03:02:52Z

Hmalipa:

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles ''Convention over configuration'' and ''Don't repeat yourself DRY''
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===
Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
Change in query interface:
In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T02:58:13Z

Hmalipa: /* ActionDispatch */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles Convention over configuration and DRY
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===
Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
Change in query interface:
In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
</pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T02:56:02Z

Hmalipa: /* ActionDispatch */

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles Convention over configuration and DRY
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===
Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
Change in query interface:
In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''

Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
<\pre>

Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''

Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''

Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T02:53:25Z

Hmalipa:

'''Rails 2 and Rails 3'''

Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles Convention over configuration and DRY
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

===Introduction===
Rails 3 has undergone many changes from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
Change in query interface:
In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''
Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
<\pre>
Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''
Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''
Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T02:51:24Z

Hmalipa:

'''Rails 2 and Rails 3'''
===Introduction===
Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles Convention over configuration and DRY
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

There are many changes in Rails 3 from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
Change in query interface:
In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''
Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
<\pre>
Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''
Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''
Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T02:50:48Z

Hmalipa: /* Introduction */

Rails 2 and Rails 3
===Introduction===
Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles Convention over configuration and DRY
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.

There are many changes in Rails 3 from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.

===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
Change in query interface:
In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''
Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
<\pre>
Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''
Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''
Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T02:50:16Z

Hmalipa: /* Rails 2 and Rails 3 */

Rails 2 and Rails 3
===Introduction===
Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles Convention over configuration and DRY
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.
There are many changes in Rails 3 from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.
===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
Change in query interface:
In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''
Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
<\pre>
Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''
Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''
Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T02:50:00Z

Hmalipa: /* Rails 2 and Rails 3 */

==Rails 2 and Rails 3==
===Introduction===
Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles Convention over configuration and DRY
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.
There are many changes in Rails 3 from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.
===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
Change in query interface:
In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''
Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
<\pre>
Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''
Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''
Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T02:46:49Z

Hmalipa: /* ActionDispatch */

=Rails 2 and Rails 3=
===Introduction===
Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles Convention over configuration and DRY
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.
There are many changes in Rails 3 from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.
===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
Change in query interface:
In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.

Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>

Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''
Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
<\pre>
Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''
Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''
Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T02:46:33Z

Hmalipa: /* ActionDispatch */

=Rails 2 and Rails 3=
===Introduction===
Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles Convention over configuration and DRY
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.
There are many changes in Rails 3 from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.
===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
Change in query interface:
In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.
Rails 2
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>
Rails 3
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''
Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
<\pre>
Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''
Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''
Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>

====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T02:43:32Z

Hmalipa: /* Performance */

=Rails 2 and Rails 3=
===Introduction===
Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles Convention over configuration and DRY
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.
There are many changes in Rails 3 from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.
===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
Change in query interface:
In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.
'''old way'''
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>
'''new way'''
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''
Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
<\pre>
Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''
Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''
Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>
====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|400px|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|400px|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T02:42:33Z

Hmalipa: /* Performance */

=Rails 2 and Rails 3=
===Introduction===
Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles Convention over configuration and DRY
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.
There are many changes in Rails 3 from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.
===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
Change in query interface:
In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.
'''old way'''
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>
'''new way'''
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''
Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
<\pre>
Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''
Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''
Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>
====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
{|
|[[File:Blog 19small-1-.jpg|alt=Alt text|center|thumb|For basic operations]]
|[[File:Blog 19big-1-.jpg|alt=Alt text|center|thumb|For complex operations]]
|}

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T02:41:11Z

Hmalipa: /* Performance */

=Rails 2 and Rails 3=
===Introduction===
Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles Convention over configuration and DRY
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.
There are many changes in Rails 3 from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.
===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
Change in query interface:
In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.
'''old way'''
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>
'''new way'''
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''
Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
<\pre>
Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''
Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''
Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>
====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
[[File:Blog 19small-1-.jpg|alt=Alt text|center|thumb|For basic operations]]
[[File:Blog 19big-1-.jpg|alt=Alt text|center|thumb|For complex operations]]

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T02:40:22Z

Hmalipa: /* Performance */

=Rails 2 and Rails 3=
===Introduction===
Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles Convention over configuration and DRY
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.
There are many changes in Rails 3 from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.
===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
Change in query interface:
In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.
'''old way'''
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>
'''new way'''
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''
Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
<\pre>
Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''
Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''
Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>
====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
[[File:Blog 19small-1-.jpg|alt=Alt text|thumb|For basic operations]]
[[File:Blog 19big-1-.jpg|alt=Alt text|thumb|For complex operations]]

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T02:38:13Z

Hmalipa: /* Performance */

=Rails 2 and Rails 3=
===Introduction===
Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles Convention over configuration and DRY
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.
There are many changes in Rails 3 from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.
===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
Change in query interface:
In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.
'''old way'''
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>
'''new way'''
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''
Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
<\pre>
Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''
Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''
Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>
====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
[[File:Blog 19small-1-.jpg|alt=Alt text|For basic operations]]
[[File:Blog 19big-1-.jpg|alt=Alt text|For complex operations]]

==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T02:36:07Z

Hmalipa:

=Rails 2 and Rails 3=
===Introduction===
Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles Convention over configuration and DRY
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.
There are many changes in Rails 3 from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.
===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
Change in query interface:
In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.
'''old way'''
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>
'''new way'''
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''
Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
<\pre>
Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''
Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''
Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>
====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
[[File:Blog 19big-1.jpg|alt=Alt text|For basic operations]]
[[File:blog_19big.jpeg|alt=Alt text|For complex operations]]
==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.

CSC/ECE 517 Fall 2011/ch2 2f vh

2011-09-23T02:35:33Z

Hmalipa:

=Rails 2 and Rails 3=
===Introduction===
Rails 3 has incorporated significant changes over its 2.x version improving on performance, modularity
and elegant constructs and thereby reinforcing its principles Convention over configuration and DRY
again. The internal architecture of the framework was refactored to make it more modular, flexible
and coherent. Routing component has been revamped and it makes lot easier configure routes.
Dependency management is also one of the significant improvements observed in 3.0. It is taken care
by new Bundler component, which automates the process of installing, updating library management.
The database operations are made much more efficient and closer to relational databases.
There are many changes in Rails 3 from architectural to syntax changes and it’s too big to discuss all
those in this article. However, this wiki article presents only major changes that are relevant to class
and at same time illustrating those concepts with examples discussed in class, especially Cookbook
Application in Rails 2. It is assumed that readers are familiar with Rails 2. With this, it serves as a
quick tutorial to understand Rails 3 features.
===Structural===
====Ruby Version====
Rails 3.0 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been
dropped officially and you should upgrade as early as possible. Rails 3.0 is also compatible with Ruby
1.9.2.
====Modularization====
Versions prior to Rails 3 were strongly coupled to a limited choices of frameworks that formed the
Rails stack. For example, a standard Rails stack used Active Record as its ORM layer, Action View for
rendering its views, PrototypeJS as its javascript library and so on.
However, with Rails 3, it has become more modular, starting with a rails-core, and including the ability
to opt in or out of specific frameworks. Its default components, like ActiveRecord and ActionController,
behave like regular plugins. This allows other plugins, like DataMapper, to use exactly the same APIs
used by ActiveRecord and hence replace it if the end user desires..
====Active Record====
Change in query interface:
In Rails 2, ActiveRecord provides the following finder methods :
<ul>
<li>find(id_or_array_of_ids, options)</li>
<li>find(:first, options)</li>
<li>find(:all, options)</li>
<li>first(options)</li>
<li>all(options)</li>
<li>update_all(updates, conditions, options)</li>
</ul>
And the following calculation methods :
<ul>
<li>count(column, options)</li>
<li>average(column, options)</li>
<li>minimum(column, options)</li>
<li>maximum(column, options)</li>
<li>sum(column, options)</li>
<li>calculate(operation, column, options)</li>
Each of these methods take an options hash
containing :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from
& :lock.
Starting with Rails 3, supplying any option has been deprecated (an exception here is that count() will
still accept a :distinct option).
Example of deprecated usage:
<pre>
User.find(:all, :limit => 1)
User.find(:all)
User.find(:first)
User.first(:conditions => {:name => 'vaibhav'})
User.all(:joins => :items)
</pre>
In Rails 3, Active Record, uses a framework – Arel, which has been taken on as the underpinnings
of Active Record and is now required for Rails. Arel is a Relational Algebra for Ruby. It simplifies the
generation complex of SQL queries and adapts to various RDBMS systems. Active Record, through
the use of Arel, now returns relations on its core methods.
ActiveRecord in Rails 3 will have the following new finder methods.

<ul>
<li>where (:conditions)</li>
<li>having (:conditions)</li>
<li>select</li>
<li>group</li>
<li>order</li>
<li>limit</li>
<li>offset</li>
<li>joins</li>
<li>includes (:include)</li>
<li>lock</li>
<li>readonly</li>
<li>from</li>
</ul>

All of the above methods returns a Relation. All these methods are defined on the Relation object as
well, making it possible to chain them.

<pre>
vaibhav = User.where(:name => 'vaibhav')
new_users = User.order('users.id DESC').limit(20).includes(:items)
</pre>

The relation returned also supports the following methods:
You could call any of the following methods on a relation :

<ul>
<li>new(attributes)</li>
<li>create(attributes)</li>
<li>create!(attributes)</li>
<li>find(id_or_array)</li>
<li>destroy(id_or_array)</li>
<li>destroy_all</li>
<li>delete(id_or_array)</li>
<li>delete_all</li>
<li>update(ids, updates)</li>
<li>update_all(updates)</li>
<li>exists?</li>
</ul>

For example, in cookbook application
In rails 2 for fetching all categories which have pizza we execute statement

<pre>
Category.find(:all, :conditions => {:recipe =>’pizza’})
</pre>
Whereas in rails 3 we have a very simple query that achieves same result by
<pre>
Category.where(:recipe => ‘pizza’)
</pre>

====Active Model Abstraction====
Active Model was extracted while decoupling Rails’ historic connection between ActiveRecord, its
default ORM, and ActionPack, its controller and view layer. All new ORM plugins (e.g. DataMapper or
Sequel) now just need to implement Active Model interfaces to work seamlessly with Action Pack. The
Active Model API itself is fairly small, with a few methods around validation, the ability to determine
whether an object has persisted or not (which can be safely stubbed by objects without persistence),
and a number of methods that tell ActionPack how to convert the object into a canonical URL or
template name. By doing this, Rails has completely decoupled ActionPack from ActiveRecord directly,
and ActiveRecord becomes just one of many ORMs to implement the ActiveModel API. An example
is the use of validations (traditionally an Active Record feature) in any Ruby object that adheres to the
Active Model API.

<pre>
class Person < ActiveRecord::Base
validates_presence_of :first_name, :last_name
end
</pre>

To do the same thing for a plain old Ruby object, simply do the following:

<pre>
class Person
include ActiveModel::Validations
validates_presence_of :first_name, :last_name
attr_accessor :first_name, :last_name
def initialize(first_name, last_name)
@first_name, @last_name = first_name, last_name
end
end
</pre>

For example, In Cookbook application discussed in class we have the recipe model class with
validations (Rails 2.x code)

<pre>
class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>

In Rails 3 we achive the same functionality by less code and has validates_presence_of method

<pre>
class Recipe
include ActiveModel::Validations
belongs_to :category
validates_presence_of :title, :instructions, :category
end
</pre>

Some other modules available in Active Model include:
<ul>
<li>AttributeMethods: Makes it easy to add attributes that are set like table_name :foo</li>
<li>Callbacks: ActiveRecord-style lifecycle callbacks.</li>
<li>Naming: Default implementations of model.model_name, which are used by ActionPack (for
instance, when you do render :partial => model</li>
<li>Observing: ActiveRecord-style observers</li>
</ul>
====Action Controller====
Previously, ActionController had a number of disparate elements all in one place. This monolithic
component is now divided into multiple pieces. Two significant componets are:
=====ActionDispatch=====
The dispatcher functionality has been moved into ActionDispatch, with the code inside tightened
up and really made a conceptual component. This has resulted in a new routing API. While the old
map.connect DSL still works just fine, the new standard DSL is less verbose and more readable.
'''old way'''
<pre>
ActionController::Routing::Routes.draw do |map|
map.connect "/main/:id", :controller => "main", :action => "home"
end
</pre>
'''new way'''
<pre>
Piazza::Application.routes do
match "/main/:id", :to => "main#home"
end
</pre>
First, the routes are attached to the application, which is now its own object. Second, map is no longer
required, and the new DSL (match/to) is more expressive. Finally, we have a shortcut for controller/
action pairs
<pre>
("main#home" is {:controller => "main", :action => "home")
</pre>
Another useful shortcut allows you to specify the method more simply than before:
<pre>
Piazza::Application.routes do
post "/main/:id", :to => "main#home", :as => :homepage
end
</pre>
The :as in the above example specifies a named route, and creates the homepage_url et al helpers as
in Rails 2.

'''Simple routes'''
Rails 2
<pre>
map.resources :posts,:member={:confirm=>:post,:notify=>:post} do |post|
post.resources :comments,:member=>{:preview=>:post},:collection=>{:archived=>:get}
end
<\pre>
Rails 3
<pre>
Resources :posts do
member do
post :confirm
get :notify
end
Resources :comments do
post :preview, <img src="http://vaibhav.com/images/smilies/icon_surprised.gif">
n=>:member
get :archived, <img src="http://harsha.com/images/smilies/icon_surprised.gif"">
n=>:collection
end
end
</pre>
'''Root mapping'''
Rails 2
<pre>
map.root :controller=>”user”
</pre>
Rails 3
<pre>
root :to=>”user#index”
</pre>
'''Legacy Route'''
Rails 2
<pre>
Map.connect ':controller/:action/:id'
Map.connect ':controller/:action/:id.:format'
</pre>
Rails 3
<pre>
Match ':controller(/:action(/:id(/:format)))
</pre>
====AbstractController====
Rails 3 has refactored ActionController and ActionMailer to inherit from a common superclass:
AbstractController. AbstractController includes the basic concept of controllers, rendering, layouts,
helpers, and callbacks, but nothing about HTTP or mail delivery.
ActionController now has AbstractController, a base superclass that is separated from the notions of
HTTP. This AbstractController handles the basic notion of controllers, actions, and action dispatching,
and not much else.
===Development===
====Rails generator system====
The new script/rails replaces all the scripts that used to be in the script directory. You do not run script/
rails directly though, the rails command detects it is being invoked in the root of a Rails application and
runs the script for you. Intended usage is:
{| class="wikitable"
|-
! Rails 2
! Rails 3
|-
| rails script/generate
| rails g
|-
| rails script/console
| rails c
|-
| rails script/server
| rails s
|-
| rails script/dbconsole
| rails db

|}
====JS library support====
Rails 2 shipped with prototypejs as the default javascript library. However, Rails 3 makes it very easy
to pick a javascript library of choice, for example you can now use jquery as the base javascript library.
===Deployment & Dependency Management===
====Bundler====
Rails 2 required specifying gems in the environment.rb files, in the config block associated with the
run method as:
<pre>
Rails::Initializer.run do |config|
config.gem "aws-s3", :lib => "aws/s3"
config.gem "fastercsv"
config.gem "chargify_api_ares"
config.gem "acts-as-taggable-on", :source => "http://gemcutter.org", :version => '2.0.0.rc1'
end
</pre>
In contrast, Rails 3 uses a Gemfile in the application root to determine the gems you require for
your application to start. This Gemfile is processed by the Bundler, which then installs all your
dependencies. It takes a gem manifest file and is able to fetch, download, and install the gems and
all child dependencies specified in this manifest. It can manage any update to the gem manifest file
and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's
gem environment.
To use bundler, declare these dependencies in a file at the root of your application, called Gemfile. It
looks something like this:
<pre>
source "http://rubygems.org"
gem "aws-s3", "1.2.0"
gem "fastercsv"
gem "chargify_api_ares"
gem "acts-as-taggable-on", "~> 1.4.2"
</pre>
Using this Gemfile, the bundler looks for gems declared in the Gemfile at http://rubygems.org. You
can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the
sources.
Next, the bundler goes through the list of dependencies declared:
<ul>
<li>version 1.2.0 of aws-s3</li>
<li>any version of fastercsv and chargify_api_ares<\li>
<li>version of acts-as-taggable-on that is >= 1.4.2 but < 1.5.0<\li>
</ul>
After declaring the dependencies, you tell bundler to go get them:
<pre>$ bundle install</pre>
Bundler will connect to rubygems.org (and any other sources that you declared), and find a list of all of
the required gems that meet the requirements you specified. Because all of the gems in your Gemfile
have dependencies of their own (and some of those have their own dependencies), running bundle
install on the Gemfile above will install quite a few gems. If any of the needed gems are already
installed, Bundler will use them. After installing any needed gems to your system, bundler writes a
snapshot of all of the gems and versions that it installed to Gemfile.lock.
On production servers, you can enable deployment mode:
$ bundle install --deployment
The --deployment flag turns on defaults that are appropriate for a deployment environment. Gems are
installed to vendor/bundle and the Gemfile.lock must be checked in and up to date before bundler is
run.
===Performance===
Rails Application object:
As part of the groundwork for supporting running multiple Rails applications in the same process,
Rails 3 introduces the concept of an Application object. An application object holds all the application
specific configurations and is very similar in nature to config/environment.rb from the previous versions
of Rails.
Each Rails application now must have a corresponding application object. The application object is
defined in config/application.rb. If you’re upgrading an existing application to Rails 3, you must add this
file and move the appropriate configurations from config/environment.rb to config/application.rb.
Rails 3 has improved performance by reducing overhead in following areas
<ul>
<li>General Controller Overhead</li>
<li>Render Collections of Partials</li>
</ul>
Here is a comparison graph of performance between Rail 2.3 vs Rails 3.0 in the above mentioned
areas.
[[File:Blog 19big-1-.jpg|alt=Alt text|For basic operations]]
[[File:blog_19big.jpeg|alt=Alt text|For complex operations]]
==References==
# Rails 3 release notes: http://edgeguides.rubyonrails.org/3_0_release_notes.html
# Yehuda Katz's posts on the merge of Rails and Merb: http://www.engineyard.com/blog/2009/rails-and-merb-merge-the-anniversary-part-1-of-6/.
# Nick Kallen's posts on AREL: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
# Bundler: http://gembundler.com/
# Pratik Naik's post on the changes in Active Record: http://m.onkey.org/active-record-query-interface
# Cookbook Application on Rails 2 discussed in class.