Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-22T18:10:57Z

Mrmanrin: /* Design by Contract */

<p style="font-size: 24px">'''Subclassing'''</p>

==Introduction==

Subclassing, or inheritance, in object-oriented programming grants the programmer the ability to extend and refine the functionality of existing classes. This principle has many advantages that can make the programmers life much more simple. Principles and techniques have been defined that support and oppose the use of subclassing, making for a great debate. Here, some of these principles will be discussed to help determine when it is a good idea to utilize subclassing in a program.

==Reasons For Subclassing==

There are many different reasons out there for why subclassing is helpful:

* '''Specialization''' - If an existing class has the basic functionality needed (ex: a circle class) but is missing some small details (say a method to determine the center of the circle), then subclassing is very useful. It allows the programmer to get most of the functionality needed and provides a means to specialize the superclass to fit the needs of the program.<ref>Skrien 2009</ref> An good example of this is the inheritance that takes place within Java's AWT graphical components<ref>Budd 2004</ref>. Each of the components you see within a GUI (Label, Button, Checkbox, etc.) are specialized versions of the Component class.

* '''Generalization''' - Two classes that are very closely related to each other could have their common functionality pulled out into a superclass and then changed to implement that superclass. This provides the programmer with less code duplication and makes it easier if a change is needed to that common functionality later on<ref>Skrien 2009</ref>. An example of this found on [http://sourcemaking.com/uml/modeling-it-systems/structural-view/generalization-specialization-and-inheritance SourceMaking.com] is the extraction of common information between a piece of luggage and a piece of cargo (identification, weight, ID number) into a superclass called freight and having the luggage and cargo classes extend the freight class<ref>SourceMaking.com</ref>. This produces the generalized freight class and lets the luggage and cargo classes become specialized.

* '''Polymorphism''' - Polymorphism is basically the utilization of a superclass type for a variable to hold a reference to an object whose class can be the supertype or any of its subtypes.<ref>Venners 1998</ref> This is a great advantage since storing a subtype into that variable would still allow the program to function correctly. In the below example, a variable that is typed as a <tt>Fruit</tt> could store the information for a <tt>Fruit</tt>, <tt>Apple</tt> or a <tt>Banana</tt>.

<pre>
class Fruit {
// . . . .
}

class Apple extends Fruit {
// . . .
}

class Banana extends Fruit {
// . . .
}

var my_fruit:Fruit = new Apple();
. . .

// Oh wait, I wanted a banana instead...
my_fruit = new Banana();
</pre>

* '''Dynamic Binding''' - This feature of subclassing allows the code executor (ex: JVM for Java) to determine at runtime which version of an overridden method to execute. This is needed because sometimes the method to execute cannot be determined at compile-time.

* '''Code Reuse''' - When a superclass is extended, the subclass inherits all of the methods and properties of the superclass. Code duplication is held to a minimum since the code is reused so effectively.

* '''Overriding and Overloading''' - Overriding and overloading functionality in a subclass is a major draw of subclassing. These abilities allow the programmer to tweak specific methods of the superclass that are close to the desired functionality in order to get the functionality exactly right.

==Reasons Not To Subclass==

* '''Inherits Too Much''' - Sometimes a programmer only needs a subset of the functionality of class. Subclassing requires that all functionality be carried down to the subclass though, often resulting in a class that has a lot of unneeded functionality. If this is done more than once in a hierarchy, then subclasses can become too bulky very quickly.

* '''Superclass Fragility''' - This issue arises because sometimes a small change in a superclass can sometimes have a ripple effect that forces changes to be made elsewhere in the code. This is usually due to poorly designed superclasses where there is not a clean separation between interface and implementation.<ref>Venners 1998</ref>

* '''Weak Encapsulation''' - This idea crops up when a subclass utilizes functionality of the superclass as it is inherited, essentially creating a case where the code from the superclass is reused. However, if changes are made to that functionality in the superclass, it could break code that directly utilizes an instance of the subclass.<ref>Venners 1998</ref>

* '''Forces Is-A Relationships''' - There is a time and a place for is-a relationships, but there are some in the field that believe "almost every is-a relationship would be better off re-articulated as a has-a relationship"<ref>Sumption 2011</ref>. Instances where two subclass functionalities need to be combined make for a hard implementation using is-a relationships. As an example, lets take the classes that follow. If we came across an instance where a TA was also a student, it would be very hard to pull in the functionality of one into the other. Composition (using has-a relationships) is a better fit here so that a Person could have the functionality of a Student, a TA, or both.

<pre>
class Person {
var name:String;

function sayHello() { . . . }
}

class Student extends Person {
var student_id:int;

function payTuition() { . . . }
}

class TA extends Person {
var class:String;

function gradeTest() { . . . }
}
</pre>

==Subclassing Principles==

===Liskov Substitution Principle===

Probably the most well-known subclassing principle is the Liskov Substitution Principle (LSP). It states:

<blockquote>If S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may be substitutes for objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.).<ref>Wikipedia - LSP</ref></blockquote>

In other words, superclasses should be replaceable by their subclasses without altering the system in any way. This principle borrows ideas from the design by contract methodology by imposing restrictions on the conditions for which the methods of a class will function. It also restricts how subclass methods can be designed in terms of their return types (covariance) and method arguments (contravariance). These restrictions provide a very good ruleset to determine whether subclassing should be utilized or not.

===Design by Contract===

The Design by Contract principle has a direct application to subclassing in its definitions of pre- and postconditions that must exist on methods. Its main goal is to provide a method to define "formal, precise and verifiable interface specifications for software components" by utilizing the idea of preconditions, postconditions and invariants<ref>Wikipedia - DbC</ref>. When used, it helps to guarantee the functionality of any software component.

Following this principle allows a programmer to weaken preconditions and strengthen postconditions and invariants, but not vice versa. Utilizing these rules comes very close to mimicking the rules applied in the Liskov substitution principle.

An example of how Design by Contract is implemented can be seen in a method that raises a number to a power (ex: 2^4 = 16)...

<pre>
// @param base - float value to be exponentiated
// @param exponent - float number of times to exponentiate
// @returns float - value of exponentiation
function exponentiate (float base, float exponent) {
// . . .
}
</pre>

From this definition, the preconditions are defined by the arguments that are required by the method (base and exponent). The comments and the typing of the variables requires the values passed in to be floating-point numbers. It is the clients responsibility to ensure that it passes in floats and not a string or an array. The postconditions are defined by the return value for the method. The comments state that it will return an floating-point value representing the end result of the exponentiation.

==References==

===Citation Notes===
<references/>

===Full References===

"Generalization, Specialization, and Inheritance" [http://sourcemaking.com/uml/modeling-it-systems/structural-view/generalization-specialization-and-inheritance http://sourcemaking.com/uml/modeling-it-systems/structural-view/generalization-specialization-and-inheritance]

Budd, Timothy. "Introduction to Object Oriented Programming, 3rd Ed Slides". [http://classes.engr.oregonstate.edu/eecs/winter2004/cs582/slides/chap08/slide16.htm http://classes.engr.oregonstate.edu/eecs/winter2004/cs582/slides/chap08/slide16.htm]. 2004

Sumption, Bernie. "Inheritance is evil, and must be destroyed". [http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/ http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/]. 2011

Skrien, Dale. "Object-Oriented Design Using Java". Boston: McGraw-Hill, 2009.

Venners, Bill. "Inheritance versus composition: Which one should you choose?" [http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html]. 1998

Wikipedia. "Design by Contract". [http://en.wikipedia.org/wiki/Design_by_Contract http://en.wikipedia.org/wiki/Design_by_Contract]

Wikipedia. "Liskov substitution principle". [http://en.wikipedia.org/wiki/Liskov_substitution_principle http://en.wikipedia.org/wiki/Liskov_substitution_principle]

===External Links===

[http://en.wikipedia.org/wiki/Liskov_substitution_principle http://en.wikipedia.org/wiki/Liskov_substitution_principle]

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-22T15:58:54Z

Mrmanrin: /* Reasons For Subclassing */

<p style="font-size: 24px">'''Subclassing'''</p>

==Introduction==

Subclassing, or inheritance, in object-oriented programming grants the programmer the ability to extend and refine the functionality of existing classes. This principle has many advantages that can make the programmers life much more simple. Principles and techniques have been defined that support and oppose the use of subclassing, making for a great debate. Here, some of these principles will be discussed to help determine when it is a good idea to utilize subclassing in a program.

==Reasons For Subclassing==

There are many different reasons out there for why subclassing is helpful:

* '''Specialization''' - If an existing class has the basic functionality needed (ex: a circle class) but is missing some small details (say a method to determine the center of the circle), then subclassing is very useful. It allows the programmer to get most of the functionality needed and provides a means to specialize the superclass to fit the needs of the program.<ref>Skrien 2009</ref> An good example of this is the inheritance that takes place within Java's AWT graphical components<ref>Budd 2004</ref>. Each of the components you see within a GUI (Label, Button, Checkbox, etc.) are specialized versions of the Component class.

* '''Generalization''' - Two classes that are very closely related to each other could have their common functionality pulled out into a superclass and then changed to implement that superclass. This provides the programmer with less code duplication and makes it easier if a change is needed to that common functionality later on<ref>Skrien 2009</ref>. An example of this found on [http://sourcemaking.com/uml/modeling-it-systems/structural-view/generalization-specialization-and-inheritance SourceMaking.com] is the extraction of common information between a piece of luggage and a piece of cargo (identification, weight, ID number) into a superclass called freight and having the luggage and cargo classes extend the freight class<ref>SourceMaking.com</ref>. This produces the generalized freight class and lets the luggage and cargo classes become specialized.

* '''Polymorphism''' - Polymorphism is basically the utilization of a superclass type for a variable to hold a reference to an object whose class can be the supertype or any of its subtypes.<ref>Venners 1998</ref> This is a great advantage since storing a subtype into that variable would still allow the program to function correctly. In the below example, a variable that is typed as a <tt>Fruit</tt> could store the information for a <tt>Fruit</tt>, <tt>Apple</tt> or a <tt>Banana</tt>.

<pre>
class Fruit {
// . . . .
}

class Apple extends Fruit {
// . . .
}

class Banana extends Fruit {
// . . .
}

var my_fruit:Fruit = new Apple();
. . .

// Oh wait, I wanted a banana instead...
my_fruit = new Banana();
</pre>

* '''Dynamic Binding''' - This feature of subclassing allows the code executor (ex: JVM for Java) to determine at runtime which version of an overridden method to execute. This is needed because sometimes the method to execute cannot be determined at compile-time.

* '''Code Reuse''' - When a superclass is extended, the subclass inherits all of the methods and properties of the superclass. Code duplication is held to a minimum since the code is reused so effectively.

* '''Overriding and Overloading''' - Overriding and overloading functionality in a subclass is a major draw of subclassing. These abilities allow the programmer to tweak specific methods of the superclass that are close to the desired functionality in order to get the functionality exactly right.

==Reasons Not To Subclass==

* '''Inherits Too Much''' - Sometimes a programmer only needs a subset of the functionality of class. Subclassing requires that all functionality be carried down to the subclass though, often resulting in a class that has a lot of unneeded functionality. If this is done more than once in a hierarchy, then subclasses can become too bulky very quickly.

* '''Superclass Fragility''' - This issue arises because sometimes a small change in a superclass can sometimes have a ripple effect that forces changes to be made elsewhere in the code. This is usually due to poorly designed superclasses where there is not a clean separation between interface and implementation.<ref>Venners 1998</ref>

* '''Weak Encapsulation''' - This idea crops up when a subclass utilizes functionality of the superclass as it is inherited, essentially creating a case where the code from the superclass is reused. However, if changes are made to that functionality in the superclass, it could break code that directly utilizes an instance of the subclass.<ref>Venners 1998</ref>

* '''Forces Is-A Relationships''' - There is a time and a place for is-a relationships, but there are some in the field that believe "almost every is-a relationship would be better off re-articulated as a has-a relationship"<ref>Sumption 2011</ref>. Instances where two subclass functionalities need to be combined make for a hard implementation using is-a relationships. As an example, lets take the classes that follow. If we came across an instance where a TA was also a student, it would be very hard to pull in the functionality of one into the other. Composition (using has-a relationships) is a better fit here so that a Person could have the functionality of a Student, a TA, or both.

<pre>
class Person {
var name:String;

function sayHello() { . . . }
}

class Student extends Person {
var student_id:int;

function payTuition() { . . . }
}

class TA extends Person {
var class:String;

function gradeTest() { . . . }
}
</pre>

==Subclassing Principles==

===Liskov Substitution Principle===

Probably the most well-known subclassing principle is the Liskov Substitution Principle (LSP). It states:

<blockquote>If S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may be substitutes for objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.).<ref>Wikipedia - LSP</ref></blockquote>

In other words, superclasses should be replaceable by their subclasses without altering the system in any way. This principle borrows ideas from the design by contract methodology by imposing restrictions on the conditions for which the methods of a class will function. It also restricts how subclass methods can be designed in terms of their return types (covariance) and method arguments (contravariance). These restrictions provide a very good ruleset to determine whether subclassing should be utilized or not.

===Design by Contract===

The Design by Contract principle has a direct application to subclassing in its definitions of pre- and postconditions that must exist on methods. Its main goal is to provide a method to define "formal, precise and verifiable interface specifications for software components" by utilizing the idea of preconditions, postconditions and invariants<ref>Wikipedia - DbC</ref>. When used, it helps to guarantee the functionality of any software component.

Following this principle allows a programmer to weaken preconditions and strengthen postconditions and invariants, but not vice versa. Utilizing these rules comes very close to mimicking the rules applied in the Liskov substitution principle.

==References==

===Citation Notes===
<references/>

===Full References===

"Generalization, Specialization, and Inheritance" [http://sourcemaking.com/uml/modeling-it-systems/structural-view/generalization-specialization-and-inheritance http://sourcemaking.com/uml/modeling-it-systems/structural-view/generalization-specialization-and-inheritance]

Budd, Timothy. "Introduction to Object Oriented Programming, 3rd Ed Slides". [http://classes.engr.oregonstate.edu/eecs/winter2004/cs582/slides/chap08/slide16.htm http://classes.engr.oregonstate.edu/eecs/winter2004/cs582/slides/chap08/slide16.htm]. 2004

Sumption, Bernie. "Inheritance is evil, and must be destroyed". [http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/ http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/]. 2011

Skrien, Dale. "Object-Oriented Design Using Java". Boston: McGraw-Hill, 2009.

Venners, Bill. "Inheritance versus composition: Which one should you choose?" [http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html]. 1998

Wikipedia. "Design by Contract". [http://en.wikipedia.org/wiki/Design_by_Contract http://en.wikipedia.org/wiki/Design_by_Contract]

Wikipedia. "Liskov substitution principle". [http://en.wikipedia.org/wiki/Liskov_substitution_principle http://en.wikipedia.org/wiki/Liskov_substitution_principle]

===External Links===

[http://en.wikipedia.org/wiki/Liskov_substitution_principle http://en.wikipedia.org/wiki/Liskov_substitution_principle]

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-22T03:27:12Z

Mrmanrin: /* References */

<p style="font-size: 24px">'''Subclassing'''</p>

==Introduction==

Subclassing, or inheritance, in object-oriented programming grants the programmer the ability to extend and refine the functionality of existing classes. This principle has many advantages that can make the programmers life much more simple. Principles and techniques have been defined that support and oppose the use of subclassing, making for a great debate. Here, some of these principles will be discussed to help determine when it is a good idea to utilize subclassing in a program.

==Reasons For Subclassing==

There are many different reasons out there for why subclassing is helpful:

* '''Specialization''' - If an existing class has the basic functionality needed (ex: a circle class) but is missing some small details (say a method to determine the center of the circle), then subclassing is very useful. It allows the programmer to get most of the functionality needed and provides a means to specialize the superclass to fit the needs of the program.<ref>Skrien 2009</ref> An good example of this is the inheritance that takes place within Java's AWT graphical components<ref>Budd 2004</ref>. Each of the components you see within a GUI (Label, Button, Checkbox, etc.) are specialized versions of the Component class.

* '''Generalization''' - Two classes that are very closely related to each other could have their common functionality pulled out into a superclass and then changed to implement that superclass. This provides the programmer with less code duplication and makes it easier if a change is needed to that common functionality later on.<ref>Skrien 2009</ref>

* '''Polymorphism''' - Polymorphism is basically the utilization of a superclass type for a variable to hold a reference to an object whose class can be the supertype or any of its subtypes.<ref>Venners 1998</ref> This is a great advantage since storing a subtype into that variable would still allow the program to function correctly. In the below example, a variable that is typed as a <tt>Fruit</tt> could store the information for a <tt>Fruit</tt>, <tt>Apple</tt> or a <tt>Banana</tt>.

<pre>
class Fruit {
// . . . .
}

class Apple extends Fruit {
// . . .
}

class Banana extends Fruit {
// . . .
}

var my_fruit:Fruit = new Apple();
. . .

// Oh wait, I wanted a banana instead...
my_fruit = new Banana();
</pre>

* '''Dynamic Binding''' - This feature of subclassing allows the code executor (ex: JVM for Java) to determine at runtime which version of an overridden method to execute. This is needed because sometimes the method to execute cannot be determined at compile-time.

* '''Code Reuse''' - When a superclass is extended, the subclass inherits all of the methods and properties of the superclass. Code duplication is held to a minimum since the code is reused so effectively.

* '''Overriding and Overloading''' - Overriding and overloading functionality in a subclass is a major draw of subclassing. These abilities allow the programmer to tweak specific methods of the superclass that are close to the desired functionality in order to get the functionality exactly right.

==Reasons Not To Subclass==

* '''Inherits Too Much''' - Sometimes a programmer only needs a subset of the functionality of class. Subclassing requires that all functionality be carried down to the subclass though, often resulting in a class that has a lot of unneeded functionality. If this is done more than once in a hierarchy, then subclasses can become too bulky very quickly.

* '''Superclass Fragility''' - This issue arises because sometimes a small change in a superclass can sometimes have a ripple effect that forces changes to be made elsewhere in the code. This is usually due to poorly designed superclasses where there is not a clean separation between interface and implementation.<ref>Venners 1998</ref>

* '''Weak Encapsulation''' - This idea crops up when a subclass utilizes functionality of the superclass as it is inherited, essentially creating a case where the code from the superclass is reused. However, if changes are made to that functionality in the superclass, it could break code that directly utilizes an instance of the subclass.<ref>Venners 1998</ref>

* '''Forces Is-A Relationships''' - There is a time and a place for is-a relationships, but there are some in the field that believe "almost every is-a relationship would be better off re-articulated as a has-a relationship"<ref>Sumption 2011</ref>. Instances where two subclass functionalities need to be combined make for a hard implementation using is-a relationships. As an example, lets take the classes that follow. If we came across an instance where a TA was also a student, it would be very hard to pull in the functionality of one into the other. Composition (using has-a relationships) is a better fit here so that a Person could have the functionality of a Student, a TA, or both.

<pre>
class Person {
var name:String;

function sayHello() { . . . }
}

class Student extends Person {
var student_id:int;

function payTuition() { . . . }
}

class TA extends Person {
var class:String;

function gradeTest() { . . . }
}
</pre>

==Subclassing Principles==

===Liskov Substitution Principle===

Probably the most well-known subclassing principle is the Liskov Substitution Principle (LSP). It states:

<blockquote>If S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may be substitutes for objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.).<ref>Wikipedia - LSP</ref></blockquote>

In other words, superclasses should be replaceable by their subclasses without altering the system in any way. This principle borrows ideas from the design by contract methodology by imposing restrictions on the conditions for which the methods of a class will function. It also restricts how subclass methods can be designed in terms of their return types (covariance) and method arguments (contravariance). These restrictions provide a very good ruleset to determine whether subclassing should be utilized or not.

===Design by Contract===

The Design by Contract principle has a direct application to subclassing in its definitions of pre- and postconditions that must exist on methods. Its main goal is to provide a method to define "formal, precise and verifiable interface specifications for software components" by utilizing the idea of preconditions, postconditions and invariants<ref>Wikipedia - DbC</ref>. When used, it helps to guarantee the functionality of any software component.

Following this principle allows a programmer to weaken preconditions and strengthen postconditions and invariants, but not vice versa. Utilizing these rules comes very close to mimicking the rules applied in the Liskov substitution principle.

==References==

===Citation Notes===
<references/>

===Full References===

"Generalization, Specialization, and Inheritance" [http://sourcemaking.com/uml/modeling-it-systems/structural-view/generalization-specialization-and-inheritance http://sourcemaking.com/uml/modeling-it-systems/structural-view/generalization-specialization-and-inheritance]

Budd, Timothy. "Introduction to Object Oriented Programming, 3rd Ed Slides". [http://classes.engr.oregonstate.edu/eecs/winter2004/cs582/slides/chap08/slide16.htm http://classes.engr.oregonstate.edu/eecs/winter2004/cs582/slides/chap08/slide16.htm]. 2004

Sumption, Bernie. "Inheritance is evil, and must be destroyed". [http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/ http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/]. 2011

Skrien, Dale. "Object-Oriented Design Using Java". Boston: McGraw-Hill, 2009.

Venners, Bill. "Inheritance versus composition: Which one should you choose?" [http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html]. 1998

Wikipedia. "Design by Contract". [http://en.wikipedia.org/wiki/Design_by_Contract http://en.wikipedia.org/wiki/Design_by_Contract]

Wikipedia. "Liskov substitution principle". [http://en.wikipedia.org/wiki/Liskov_substitution_principle http://en.wikipedia.org/wiki/Liskov_substitution_principle]

===External Links===

[http://en.wikipedia.org/wiki/Liskov_substitution_principle http://en.wikipedia.org/wiki/Liskov_substitution_principle]

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-22T03:24:31Z

Mrmanrin: /* References */

<p style="font-size: 24px">'''Subclassing'''</p>

==Introduction==

Subclassing, or inheritance, in object-oriented programming grants the programmer the ability to extend and refine the functionality of existing classes. This principle has many advantages that can make the programmers life much more simple. Principles and techniques have been defined that support and oppose the use of subclassing, making for a great debate. Here, some of these principles will be discussed to help determine when it is a good idea to utilize subclassing in a program.

==Reasons For Subclassing==

There are many different reasons out there for why subclassing is helpful:

* '''Specialization''' - If an existing class has the basic functionality needed (ex: a circle class) but is missing some small details (say a method to determine the center of the circle), then subclassing is very useful. It allows the programmer to get most of the functionality needed and provides a means to specialize the superclass to fit the needs of the program.<ref>Skrien 2009</ref> An good example of this is the inheritance that takes place within Java's AWT graphical components<ref>Budd 2004</ref>. Each of the components you see within a GUI (Label, Button, Checkbox, etc.) are specialized versions of the Component class.

* '''Generalization''' - Two classes that are very closely related to each other could have their common functionality pulled out into a superclass and then changed to implement that superclass. This provides the programmer with less code duplication and makes it easier if a change is needed to that common functionality later on.<ref>Skrien 2009</ref>

* '''Polymorphism''' - Polymorphism is basically the utilization of a superclass type for a variable to hold a reference to an object whose class can be the supertype or any of its subtypes.<ref>Venners 1998</ref> This is a great advantage since storing a subtype into that variable would still allow the program to function correctly. In the below example, a variable that is typed as a <tt>Fruit</tt> could store the information for a <tt>Fruit</tt>, <tt>Apple</tt> or a <tt>Banana</tt>.

<pre>
class Fruit {
// . . . .
}

class Apple extends Fruit {
// . . .
}

class Banana extends Fruit {
// . . .
}

var my_fruit:Fruit = new Apple();
. . .

// Oh wait, I wanted a banana instead...
my_fruit = new Banana();
</pre>

* '''Dynamic Binding''' - This feature of subclassing allows the code executor (ex: JVM for Java) to determine at runtime which version of an overridden method to execute. This is needed because sometimes the method to execute cannot be determined at compile-time.

* '''Code Reuse''' - When a superclass is extended, the subclass inherits all of the methods and properties of the superclass. Code duplication is held to a minimum since the code is reused so effectively.

* '''Overriding and Overloading''' - Overriding and overloading functionality in a subclass is a major draw of subclassing. These abilities allow the programmer to tweak specific methods of the superclass that are close to the desired functionality in order to get the functionality exactly right.

==Reasons Not To Subclass==

* '''Inherits Too Much''' - Sometimes a programmer only needs a subset of the functionality of class. Subclassing requires that all functionality be carried down to the subclass though, often resulting in a class that has a lot of unneeded functionality. If this is done more than once in a hierarchy, then subclasses can become too bulky very quickly.

* '''Superclass Fragility''' - This issue arises because sometimes a small change in a superclass can sometimes have a ripple effect that forces changes to be made elsewhere in the code. This is usually due to poorly designed superclasses where there is not a clean separation between interface and implementation.<ref>Venners 1998</ref>

* '''Weak Encapsulation''' - This idea crops up when a subclass utilizes functionality of the superclass as it is inherited, essentially creating a case where the code from the superclass is reused. However, if changes are made to that functionality in the superclass, it could break code that directly utilizes an instance of the subclass.<ref>Venners 1998</ref>

* '''Forces Is-A Relationships''' - There is a time and a place for is-a relationships, but there are some in the field that believe "almost every is-a relationship would be better off re-articulated as a has-a relationship"<ref>Sumption 2011</ref>. Instances where two subclass functionalities need to be combined make for a hard implementation using is-a relationships. As an example, lets take the classes that follow. If we came across an instance where a TA was also a student, it would be very hard to pull in the functionality of one into the other. Composition (using has-a relationships) is a better fit here so that a Person could have the functionality of a Student, a TA, or both.

<pre>
class Person {
var name:String;

function sayHello() { . . . }
}

class Student extends Person {
var student_id:int;

function payTuition() { . . . }
}

class TA extends Person {
var class:String;

function gradeTest() { . . . }
}
</pre>

==Subclassing Principles==

===Liskov Substitution Principle===

Probably the most well-known subclassing principle is the Liskov Substitution Principle (LSP). It states:

<blockquote>If S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may be substitutes for objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.).<ref>Wikipedia - LSP</ref></blockquote>

In other words, superclasses should be replaceable by their subclasses without altering the system in any way. This principle borrows ideas from the design by contract methodology by imposing restrictions on the conditions for which the methods of a class will function. It also restricts how subclass methods can be designed in terms of their return types (covariance) and method arguments (contravariance). These restrictions provide a very good ruleset to determine whether subclassing should be utilized or not.

===Design by Contract===

The Design by Contract principle has a direct application to subclassing in its definitions of pre- and postconditions that must exist on methods. Its main goal is to provide a method to define "formal, precise and verifiable interface specifications for software components" by utilizing the idea of preconditions, postconditions and invariants<ref>Wikipedia - DbC</ref>. When used, it helps to guarantee the functionality of any software component.

Following this principle allows a programmer to weaken preconditions and strengthen postconditions and invariants, but not vice versa. Utilizing these rules comes very close to mimicking the rules applied in the Liskov substitution principle.

==References==

===Citation Notes===
<references/>

===Full References===

Budd, Timothy. "Introduction to Object Oriented Programming, 3rd Ed Slides". [http://classes.engr.oregonstate.edu/eecs/winter2004/cs582/slides/chap08/slide16.htm http://classes.engr.oregonstate.edu/eecs/winter2004/cs582/slides/chap08/slide16.htm]. 2004

Sumption, Bernie. "Inheritance is evil, and must be destroyed". [http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/ http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/]. 2011

Skrien, Dale. "Object-Oriented Design Using Java". Boston: McGraw-Hill, 2009.

Venners, Bill. "Inheritance versus composition: Which one should you choose?" [http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html]. 1998

Wikipedia. "Design by Contract". [http://en.wikipedia.org/wiki/Design_by_Contract http://en.wikipedia.org/wiki/Design_by_Contract]

Wikipedia. "Liskov substitution principle". [http://en.wikipedia.org/wiki/Liskov_substitution_principle http://en.wikipedia.org/wiki/Liskov_substitution_principle]

===External Links===

[http://en.wikipedia.org/wiki/Liskov_substitution_principle http://en.wikipedia.org/wiki/Liskov_substitution_principle]

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-22T03:23:28Z

Mrmanrin: /* Reasons For Subclassing */

<p style="font-size: 24px">'''Subclassing'''</p>

==Introduction==

Subclassing, or inheritance, in object-oriented programming grants the programmer the ability to extend and refine the functionality of existing classes. This principle has many advantages that can make the programmers life much more simple. Principles and techniques have been defined that support and oppose the use of subclassing, making for a great debate. Here, some of these principles will be discussed to help determine when it is a good idea to utilize subclassing in a program.

==Reasons For Subclassing==

There are many different reasons out there for why subclassing is helpful:

* '''Specialization''' - If an existing class has the basic functionality needed (ex: a circle class) but is missing some small details (say a method to determine the center of the circle), then subclassing is very useful. It allows the programmer to get most of the functionality needed and provides a means to specialize the superclass to fit the needs of the program.<ref>Skrien 2009</ref> An good example of this is the inheritance that takes place within Java's AWT graphical components<ref>Budd 2004</ref>. Each of the components you see within a GUI (Label, Button, Checkbox, etc.) are specialized versions of the Component class.

* '''Generalization''' - Two classes that are very closely related to each other could have their common functionality pulled out into a superclass and then changed to implement that superclass. This provides the programmer with less code duplication and makes it easier if a change is needed to that common functionality later on.<ref>Skrien 2009</ref>

* '''Polymorphism''' - Polymorphism is basically the utilization of a superclass type for a variable to hold a reference to an object whose class can be the supertype or any of its subtypes.<ref>Venners 1998</ref> This is a great advantage since storing a subtype into that variable would still allow the program to function correctly. In the below example, a variable that is typed as a <tt>Fruit</tt> could store the information for a <tt>Fruit</tt>, <tt>Apple</tt> or a <tt>Banana</tt>.

<pre>
class Fruit {
// . . . .
}

class Apple extends Fruit {
// . . .
}

class Banana extends Fruit {
// . . .
}

var my_fruit:Fruit = new Apple();
. . .

// Oh wait, I wanted a banana instead...
my_fruit = new Banana();
</pre>

* '''Dynamic Binding''' - This feature of subclassing allows the code executor (ex: JVM for Java) to determine at runtime which version of an overridden method to execute. This is needed because sometimes the method to execute cannot be determined at compile-time.

* '''Code Reuse''' - When a superclass is extended, the subclass inherits all of the methods and properties of the superclass. Code duplication is held to a minimum since the code is reused so effectively.

* '''Overriding and Overloading''' - Overriding and overloading functionality in a subclass is a major draw of subclassing. These abilities allow the programmer to tweak specific methods of the superclass that are close to the desired functionality in order to get the functionality exactly right.

==Reasons Not To Subclass==

* '''Inherits Too Much''' - Sometimes a programmer only needs a subset of the functionality of class. Subclassing requires that all functionality be carried down to the subclass though, often resulting in a class that has a lot of unneeded functionality. If this is done more than once in a hierarchy, then subclasses can become too bulky very quickly.

* '''Superclass Fragility''' - This issue arises because sometimes a small change in a superclass can sometimes have a ripple effect that forces changes to be made elsewhere in the code. This is usually due to poorly designed superclasses where there is not a clean separation between interface and implementation.<ref>Venners 1998</ref>

* '''Weak Encapsulation''' - This idea crops up when a subclass utilizes functionality of the superclass as it is inherited, essentially creating a case where the code from the superclass is reused. However, if changes are made to that functionality in the superclass, it could break code that directly utilizes an instance of the subclass.<ref>Venners 1998</ref>

* '''Forces Is-A Relationships''' - There is a time and a place for is-a relationships, but there are some in the field that believe "almost every is-a relationship would be better off re-articulated as a has-a relationship"<ref>Sumption 2011</ref>. Instances where two subclass functionalities need to be combined make for a hard implementation using is-a relationships. As an example, lets take the classes that follow. If we came across an instance where a TA was also a student, it would be very hard to pull in the functionality of one into the other. Composition (using has-a relationships) is a better fit here so that a Person could have the functionality of a Student, a TA, or both.

<pre>
class Person {
var name:String;

function sayHello() { . . . }
}

class Student extends Person {
var student_id:int;

function payTuition() { . . . }
}

class TA extends Person {
var class:String;

function gradeTest() { . . . }
}
</pre>

==Subclassing Principles==

===Liskov Substitution Principle===

Probably the most well-known subclassing principle is the Liskov Substitution Principle (LSP). It states:

<blockquote>If S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may be substitutes for objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.).<ref>Wikipedia - LSP</ref></blockquote>

In other words, superclasses should be replaceable by their subclasses without altering the system in any way. This principle borrows ideas from the design by contract methodology by imposing restrictions on the conditions for which the methods of a class will function. It also restricts how subclass methods can be designed in terms of their return types (covariance) and method arguments (contravariance). These restrictions provide a very good ruleset to determine whether subclassing should be utilized or not.

===Design by Contract===

The Design by Contract principle has a direct application to subclassing in its definitions of pre- and postconditions that must exist on methods. Its main goal is to provide a method to define "formal, precise and verifiable interface specifications for software components" by utilizing the idea of preconditions, postconditions and invariants<ref>Wikipedia - DbC</ref>. When used, it helps to guarantee the functionality of any software component.

Following this principle allows a programmer to weaken preconditions and strengthen postconditions and invariants, but not vice versa. Utilizing these rules comes very close to mimicking the rules applied in the Liskov substitution principle.

==References==

===Citation Notes===
<references/>

===Full References===

Sumption, Bernie. "Inheritance is evil, and must be destroyed". [http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/ http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/]. 2011

Skrien, Dale. "Object-Oriented Design Using Java". Boston: McGraw-Hill, 2009.

Venners, Bill. "Inheritance versus composition: Which one should you choose?" [http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html]. 1998

Wikipedia. "Design by Contract". [http://en.wikipedia.org/wiki/Design_by_Contract http://en.wikipedia.org/wiki/Design_by_Contract]

Wikipedia. "Liskov substitution principle". [http://en.wikipedia.org/wiki/Liskov_substitution_principle http://en.wikipedia.org/wiki/Liskov_substitution_principle]

===External Links===

[http://en.wikipedia.org/wiki/Liskov_substitution_principle http://en.wikipedia.org/wiki/Liskov_substitution_principle]

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-22T02:23:52Z

Mrmanrin: /* Reasons For Subclassing */

<p style="font-size: 24px">'''Subclassing'''</p>

==Introduction==

Subclassing, or inheritance, in object-oriented programming grants the programmer the ability to extend and refine the functionality of existing classes. This principle has many advantages that can make the programmers life much more simple. Principles and techniques have been defined that support and oppose the use of subclassing, making for a great debate. Here, some of these principles will be discussed to help determine when it is a good idea to utilize subclassing in a program.

==Reasons For Subclassing==

There are many different reasons out there for why subclassing is helpful:

* '''Specialization''' - If an existing class has the basic functionality needed (ex: a circle class) but is missing some small details (say a method to determine the center of the circle), then subclassing is very useful. It allows the programmer to get most of the functionality needed and provides a means to specialize the superclass to fit the needs of the program.<ref>Skrien 2009</ref>

* '''Generalization''' - Two classes that are very closely related to each other could have their common functionality pulled out into a superclass and then changed to implement that superclass. This provides the programmer with less code duplication and makes it easier if a change is needed to that common functionality later on.<ref>Skrien 2009</ref>

* '''Polymorphism''' - Polymorphism is basically the utilization of a superclass type for a variable to hold a reference to an object whose class can be the supertype or any of its subtypes.<ref>Venners 1998</ref> This is a great advantage since storing a subtype into that variable would still allow the program to function correctly. In the below example, a variable that is typed as a <tt>Fruit</tt> could store the information for a <tt>Fruit</tt>, <tt>Apple</tt> or a <tt>Banana</tt>.

<pre>
class Fruit {
// . . . .
}

class Apple extends Fruit {
// . . .
}

class Banana extends Fruit {
// . . .
}

var my_fruit:Fruit = new Apple();
. . .

// Oh wait, I wanted a banana instead...
my_fruit = new Banana();
</pre>

* '''Dynamic Binding''' - This feature of subclassing allows the code executor (ex: JVM for Java) to determine at runtime which version of an overridden method to execute. This is needed because sometimes the method to execute cannot be determined at compile-time.

* '''Code Reuse''' - When a superclass is extended, the subclass inherits all of the methods and properties of the superclass. Code duplication is held to a minimum since the code is reused so effectively.

* '''Overriding and Overloading''' - Overriding and overloading functionality in a subclass is a major draw of subclassing. These abilities allow the programmer to tweak specific methods of the superclass that are close to the desired functionality in order to get the functionality exactly right.

==Reasons Not To Subclass==

* '''Inherits Too Much''' - Sometimes a programmer only needs a subset of the functionality of class. Subclassing requires that all functionality be carried down to the subclass though, often resulting in a class that has a lot of unneeded functionality. If this is done more than once in a hierarchy, then subclasses can become too bulky very quickly.

* '''Superclass Fragility''' - This issue arises because sometimes a small change in a superclass can sometimes have a ripple effect that forces changes to be made elsewhere in the code. This is usually due to poorly designed superclasses where there is not a clean separation between interface and implementation.<ref>Venners 1998</ref>

* '''Weak Encapsulation''' - This idea crops up when a subclass utilizes functionality of the superclass as it is inherited, essentially creating a case where the code from the superclass is reused. However, if changes are made to that functionality in the superclass, it could break code that directly utilizes an instance of the subclass.<ref>Venners 1998</ref>

* '''Forces Is-A Relationships''' - There is a time and a place for is-a relationships, but there are some in the field that believe "almost every is-a relationship would be better off re-articulated as a has-a relationship"<ref>Sumption 2011</ref>. Instances where two subclass functionalities need to be combined make for a hard implementation using is-a relationships. As an example, lets take the classes that follow. If we came across an instance where a TA was also a student, it would be very hard to pull in the functionality of one into the other. Composition (using has-a relationships) is a better fit here so that a Person could have the functionality of a Student, a TA, or both.

<pre>
class Person {
var name:String;

function sayHello() { . . . }
}

class Student extends Person {
var student_id:int;

function payTuition() { . . . }
}

class TA extends Person {
var class:String;

function gradeTest() { . . . }
}
</pre>

==Subclassing Principles==

===Liskov Substitution Principle===

Probably the most well-known subclassing principle is the Liskov Substitution Principle (LSP). It states:

<blockquote>If S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may be substitutes for objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.).<ref>Wikipedia - LSP</ref></blockquote>

In other words, superclasses should be replaceable by their subclasses without altering the system in any way. This principle borrows ideas from the design by contract methodology by imposing restrictions on the conditions for which the methods of a class will function. It also restricts how subclass methods can be designed in terms of their return types (covariance) and method arguments (contravariance). These restrictions provide a very good ruleset to determine whether subclassing should be utilized or not.

===Design by Contract===

The Design by Contract principle has a direct application to subclassing in its definitions of pre- and postconditions that must exist on methods. Its main goal is to provide a method to define "formal, precise and verifiable interface specifications for software components" by utilizing the idea of preconditions, postconditions and invariants<ref>Wikipedia - DbC</ref>. When used, it helps to guarantee the functionality of any software component.

Following this principle allows a programmer to weaken preconditions and strengthen postconditions and invariants, but not vice versa. Utilizing these rules comes very close to mimicking the rules applied in the Liskov substitution principle.

==References==

===Citation Notes===
<references/>

===Full References===

Sumption, Bernie. "Inheritance is evil, and must be destroyed". [http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/ http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/]. 2011

Skrien, Dale. "Object-Oriented Design Using Java". Boston: McGraw-Hill, 2009.

Venners, Bill. "Inheritance versus composition: Which one should you choose?" [http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html]. 1998

Wikipedia. "Design by Contract". [http://en.wikipedia.org/wiki/Design_by_Contract http://en.wikipedia.org/wiki/Design_by_Contract]

Wikipedia. "Liskov substitution principle". [http://en.wikipedia.org/wiki/Liskov_substitution_principle http://en.wikipedia.org/wiki/Liskov_substitution_principle]

===External Links===

[http://en.wikipedia.org/wiki/Liskov_substitution_principle http://en.wikipedia.org/wiki/Liskov_substitution_principle]

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-22T02:19:20Z

Mrmanrin: /* Reasons Not To Subclass */

<p style="font-size: 24px">'''Subclassing'''</p>

==Introduction==

Subclassing, or inheritance, in object-oriented programming grants the programmer the ability to extend and refine the functionality of existing classes. This principle has many advantages that can make the programmers life much more simple. Principles and techniques have been defined that support and oppose the use of subclassing, making for a great debate. Here, some of these principles will be discussed to help determine when it is a good idea to utilize subclassing in a program.

==Reasons For Subclassing==

There are many different reasons out there for why subclassing is helpful:

* '''Specialization''' - If an existing class has the basic functionality needed (ex: a circle class) but is missing some small details (say a method to determine the center of the circle), then subclassing is very useful. It allows the programmer to get most of the functionality needed and provides a means to specialize the superclass to fit the needs of the program.<ref>Skrien 2009</ref>

* '''Generalization''' - Two classes that are very closely related to each other could have their common functionality pulled out into a superclass and then changed to implement that superclass. This provides the programmer with less code duplication and makes it easier if a change is needed to that common functionality later on.<ref>Skrien 2009</ref>

* '''Polymorphism''' - Polymorphism is basically the utilization of a superclass type for a variable to hold a reference to an object whose class can be the supertype or any of its subtypes.<ref>Venners 1998</ref> This is a great advantage since storing a subtype into that variable would still allow the program to function correctly.

* '''Dynamic Binding''' - This feature of subclassing allows the code executor (ex: JVM for Java) to determine at runtime which version of an overridden method to execute. This is needed because sometimes the method to execute cannot be determined at compile-time.

* '''Code Reuse''' - When a superclass is extended, the subclass inherits all of the methods and properties of the superclass. Code duplication is held to a minimum since the code is reused so effectively.

* '''Overriding and Overloading''' - Overriding and overloading functionality in a subclass is a major draw of subclassing. These abilities allow the programmer to tweak specific methods of the superclass that are close to the desired functionality in order to get the functionality exactly right.

==Reasons Not To Subclass==

* '''Inherits Too Much''' - Sometimes a programmer only needs a subset of the functionality of class. Subclassing requires that all functionality be carried down to the subclass though, often resulting in a class that has a lot of unneeded functionality. If this is done more than once in a hierarchy, then subclasses can become too bulky very quickly.

* '''Superclass Fragility''' - This issue arises because sometimes a small change in a superclass can sometimes have a ripple effect that forces changes to be made elsewhere in the code. This is usually due to poorly designed superclasses where there is not a clean separation between interface and implementation.<ref>Venners 1998</ref>

* '''Weak Encapsulation''' - This idea crops up when a subclass utilizes functionality of the superclass as it is inherited, essentially creating a case where the code from the superclass is reused. However, if changes are made to that functionality in the superclass, it could break code that directly utilizes an instance of the subclass.<ref>Venners 1998</ref>

* '''Forces Is-A Relationships''' - There is a time and a place for is-a relationships, but there are some in the field that believe "almost every is-a relationship would be better off re-articulated as a has-a relationship"<ref>Sumption 2011</ref>. Instances where two subclass functionalities need to be combined make for a hard implementation using is-a relationships. As an example, lets take the classes that follow. If we came across an instance where a TA was also a student, it would be very hard to pull in the functionality of one into the other. Composition (using has-a relationships) is a better fit here so that a Person could have the functionality of a Student, a TA, or both.

<pre>
class Person {
var name:String;

function sayHello() { . . . }
}

class Student extends Person {
var student_id:int;

function payTuition() { . . . }
}

class TA extends Person {
var class:String;

function gradeTest() { . . . }
}
</pre>

==Subclassing Principles==

===Liskov Substitution Principle===

Probably the most well-known subclassing principle is the Liskov Substitution Principle (LSP). It states:

<blockquote>If S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may be substitutes for objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.).<ref>Wikipedia - LSP</ref></blockquote>

In other words, superclasses should be replaceable by their subclasses without altering the system in any way. This principle borrows ideas from the design by contract methodology by imposing restrictions on the conditions for which the methods of a class will function. It also restricts how subclass methods can be designed in terms of their return types (covariance) and method arguments (contravariance). These restrictions provide a very good ruleset to determine whether subclassing should be utilized or not.

===Design by Contract===

The Design by Contract principle has a direct application to subclassing in its definitions of pre- and postconditions that must exist on methods. Its main goal is to provide a method to define "formal, precise and verifiable interface specifications for software components" by utilizing the idea of preconditions, postconditions and invariants<ref>Wikipedia - DbC</ref>. When used, it helps to guarantee the functionality of any software component.

Following this principle allows a programmer to weaken preconditions and strengthen postconditions and invariants, but not vice versa. Utilizing these rules comes very close to mimicking the rules applied in the Liskov substitution principle.

==References==

===Citation Notes===
<references/>

===Full References===

Sumption, Bernie. "Inheritance is evil, and must be destroyed". [http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/ http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/]. 2011

Skrien, Dale. "Object-Oriented Design Using Java". Boston: McGraw-Hill, 2009.

Venners, Bill. "Inheritance versus composition: Which one should you choose?" [http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html]. 1998

Wikipedia. "Design by Contract". [http://en.wikipedia.org/wiki/Design_by_Contract http://en.wikipedia.org/wiki/Design_by_Contract]

Wikipedia. "Liskov substitution principle". [http://en.wikipedia.org/wiki/Liskov_substitution_principle http://en.wikipedia.org/wiki/Liskov_substitution_principle]

===External Links===

[http://en.wikipedia.org/wiki/Liskov_substitution_principle http://en.wikipedia.org/wiki/Liskov_substitution_principle]

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-22T02:05:12Z

Mrmanrin: /* Full References */

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-22T02:04:31Z

Mrmanrin: /* Reasons Not To Subclass */

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-16T03:01:31Z

Mrmanrin: /* Full References */

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-16T02:56:05Z

Mrmanrin: /* Reasons For Subclassing */

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-16T02:54:38Z

Mrmanrin: /* Reasons For Subclassing */

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-16T02:51:59Z

Mrmanrin: /* Reasons For Subclassing */

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-15T21:27:11Z

Mrmanrin: /* Full References */

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-15T21:26:41Z

Mrmanrin: /* Subclassing Principles */

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-15T21:18:34Z

Mrmanrin: /* References */

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-15T21:16:14Z

Mrmanrin: /* Full References */

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-15T21:13:53Z

Mrmanrin:

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-15T06:51:14Z

Mrmanrin:

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-15T06:35:05Z

Mrmanrin:

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-15T06:23:34Z

Mrmanrin:

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-15T06:19:33Z

Mrmanrin:

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-15T06:18:36Z

Mrmanrin:

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-15T05:46:08Z

Mrmanrin:

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-15T05:45:18Z

Mrmanrin: /* Liskov Substitution Principle */

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-15T05:44:17Z

Mrmanrin: /* References */

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-15T05:42:39Z

Mrmanrin:

CSC/ECE 517 Fall 2011

2011-11-09T03:56:36Z

Mrmanrin:

[[Link title]]
*[[CSC/ECE 517 Fall 2011/ch1 1a ms]]

*[[CSC/ECE 517 Fall 2011/ch1 1a cs]]

*[[CSC/ECE 517 Fall 2011/ch1 1a ri]]

*[[CSC/ECE 517 Fall 2011/ch1 1a lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1b sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1b ds]]

*[[CSC/ECE 517 Fall 2011/ch1 1b tj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c cm]]

*[[CSC/ECE 517 Fall 2011/ch1 1c sj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c ka]]

*[[CSC/ECE 517 Fall 2011/ch1 1d sr]]

*[[CSC/ECE 517 Fall 2011/ch1 1e vs]]

*[[CSC/ECE 517 Fall 2011/ch1 1e aa]]

*[[CSC/ECE 517 Fall 2011/ch1 1a sc]]

*[[CSC/ECE 517 Fall 2011/ch1 1e dm]]

*[[CSC/ECE 517 Fall 2011/ch1 1e an]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1e lm]]

*[[CSC/ECE 517 Fall 2011/ch1 1g vn]]

*[[CSC/ECE 517 Fall 2011/ch1 1f rs]]

*[[CSC/ECE 517 Fall 2011/ch1 1f sv]]

*[[CSC/ECE 517 Fall 2011/ch1 1g jn]]

*[[CSC/ECE 517 Fall 2011/ch1 1h ps]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sm]]

*[[CSC/ECE 517 Fall 2011/ch1 1i zf]]

*[[CSC/ECE 517 Fall 2011/ch1 1g rn]]

*[[CSC/ECE 517 Fall 2011/ch1 1i cl]]

*[[CSC/ECE 517 Fall 2011/ch1 1d ss]]

*[[CSC/ECE 517 Fall 2011/ch1 1i lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1h hs]]

*[[CSC/ECE 517 Fall 2011/ch1 1d gs]]

*[[CSC/ECE 517 Fall 2011/ch1 2b ns]]

*[[CSC/ECE 517 Fall 2011/ch1 2b jp]]

*[[CSC/ECE 517 Fall 2011/ch1 2a av]]

*[[CSC/ECE 517 Fall 2011/ch2 2f jm]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ad]]

*[[CSC/ECE 517 Fall 2011/ch2 2e kt]]

*[[CSC/ECE 517 Fall 2011/ch2 2e gp]]

*[[CSC/ECE 517 Fall 2011/ch1 2b qu]]

*[[CSC/ECE 517 Fall 2011/ch2 2c bs]]

*[[CSC/ECE 517 Fall 2011/ch1 2c rs]]

*[[CSC/ECE 517 Fall 2011/ch1 2a ca]]

*[[CSC/ECE 517 Fall 2011/ch1 2b rv]]

*[[CSC/ECE 517 Fall 2011/ch2 2c ds]]

*[[CSC/ECE 517 Fall 2011/ch2 2b sa]]

*[[CSC/ECE 517 Fall 2011/ch2 2f mm]]

*[[CSC/ECE 517 Fall 2011/ch2 2f vh]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ps]]

*[[CSC/ECE 517 Fall 2011/ch3 3a oe]]

*[[CSC/ECE 517 Fall 2011/ch3 3h rr]]

*[[CSC/ECE 517 Fall 2011/ch3 3h ss]]

*[[CSC/ECE 517 Fall 2011/ch3 4b js]]

*[[CSC/ECE 517 Fall 2011/ch3 4b ms]]

*[[CSC/ECE 517 Fall 2011/ch4 4b ds]]

*[[CSC/ECE 517 Fall 2011/ch4 4i aa]]

*[[CSC/ECE 517 Fall 2011/ch4 4i sd]]

*[[CSC/ECE 517 Fall 2011/ch4 4d mt]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ls]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ch]]

*[[CSC/ECE 517 Fall 2011/ch4 4c ap]]

*[[CSC/ECE 517 Fall 2011/ch4 4h sv]]

*[[CSC/ECE 517 Fall 2011/ch4 4e cl]]

*[[CSC/ECE 517 Fall 2011/ch4 4e gs]]

*[[CSC/ECE 517 Fall 2011/ch4 4a ga]]

*[[CSC/ECE 517 Fall 2011/ch4 4f sl]]

*[[CSC/ECE 517 Fall 2011/ch4 4i js]]

*[[CSC/ECE 517 Fall 2011/ch4 4f ss]]

*[[CSC/ECE 517 Fall 2011/ch4 4c dm]]

*[[CSC/ECE 517 Fall 2011/ch4 4g as]]

*[[CSC/ECE 517 Fall 2011/ch4 4g nv]]

*[[CSC/ECE 517 Fall 2011/ch4 4g ms]]

*[[CSC/ECE 517 Fall 2011/ch4 4h kp]]

*[[CSC/ECE 517 Fall 2011/ch4 4h as]]

*[[CSC/ECE 517 Fall 2011/ch4 4j fw]]

*[[CSC/ECE 517 Fall 2011/ch4 4f rs]]

*[[CSC/ECE 517 Fall 2011/ch4 4i lc]]

*[[CSC/ECE 517 Fall 2011/ch17 5b uo]]

*[[CSC/ECE 517 Fall 2011/ch17 5b br]]

*[[CSC/ECE 517 Fall 2011/ch5 5d he]]

*[[CSC/ECE 517 Fall 2011/ch5 6d ny]]

*[[trial]]

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-09T03:52:28Z

Mrmanrin:

<p style="font-size: 24px">'''Subclassing'''</p>

==Definition==

==When To Use It==

===Code Reuse===

===Is-A Relationships===

===Public Interfaces===

===Polymorphism===

==Drawbacks==

===Yo-Yo Effect===

===Tight Coupling===

==Examples==

==References==

===Citation Notes===

===Full References===

===External Links===

CSC/ECE 517 Fall 2011/ch6 6b mm

2011-11-09T03:49:12Z

Mrmanrin: Created page with "=Subclassing= ==Definition== ==When To Use It== ==Examples== ==References== ===Citation Notes=== ===Full References=== ===External Links==="

=Subclassing=

==Definition==

==When To Use It==

==Examples==

==References==

===Citation Notes===

===Full References===

===External Links===

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T19:30:40Z

Mrmanrin: /* Rails 2 vs. Rails 3 */

=Introduction=
The original Ruby on Rails platform was extracted from the web-based project-management tool called Basecamp developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project. [REFERENCE] Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of Convention over Configuration [WIKI LINK] and Don’t Repeat Yourself (DRY) [WIKI LINK].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades.

===Rails 1.0===
Initially, Rails 1.0 was released 15 months after the original source was made available. [REFERENCE] This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

===Rails 2.0 ===
Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

===Rails 2.3===
The next major update was Rails 2.3 at it was the most structural update prior to Rails 3.0 being released. The two primary changes in the architecture of the Rails application was the complete integration of the Rack modular web server interface and a renewed support for Rails Engines. {link 2} Alongside of these changes were updates to templates, the addition of built-in support for HTTP Digest Authentication, nested forms models, Metal, and improved caching performance among other things.

===Rails 3.0===
Between Rails 2.3 and the release of Rails 3.0, Rails announced that it would merge with Merb and that Rails 3.0 would be the successor to both Rails 2 and Merb. Merb which is short for Mongrel+Erb, key feature that prompted the join Rails was its component modularity, extensible API design, and vertical scalability.

=Rails 2 vs. Rails 3=

As you can see a lot changed since the first release of Rails. We will explore a few of the key areas that changed between Rails 2 and Rails 3 that will affect a developer's everyday coding.

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

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

==Gem Dependencies==

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

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

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==
Active Record, like all of the core Rails components, got a major overhaul.

===Arel and the Query Interface===
The most prominent changes made that will be apparent to developers will be the integration with [https://github.com/nkallen/arel Arel]. With this integration, all of the core methods for Active Record return relations, allowing them to be chained together to develop complex queries. A full list and their functionality can be found in the [http://guides.rubyonrails.org/active_record_querying.html Rails Guide]. This will take the place of the options hash that would normally get passed in to one of the Active Record methods. To illustrate this, say we wanted to get a list of the first 10 products ordered alphabetically:

<pre>
# Rails 2
Product.find(:order => "name DESC", :limit => 10)

# Rails 3
Product.order("name DESC").limit(10)
</pre>

Also, there are a lot of methods that are losing the options parameter in their definitions<ref>Naik 2010</ref>, including query methods find and all as well as calculation methods count and average. Also, the <tt>:all</tt> and <tt>:first</tt> parameters for the find method are being deprecated in favor of the <tt>all</tt> and <tt>first</tt> methods. Here are some examples of how things are changing:

<pre>
# Changes to the find method.
# Rails 2
Product.find(:all)
Product.find(:first)

# Rails 3
Product.all
Product.first

# Examples of method options being removed.
# Rails 2
Product.all(:joins => :categories)

# Rails 3
Product.joins("categories")
</pre>

===Named Scopes===
The <tt>named_scope</tt> definition has been changed to just <tt>scope</tt>. The options hash is also being deprecated and should be replaced with the new methods provided by the Arel integration. Translating existing Rails 2 named scopes is easy enough:

<pre>
# Rails 2
class Product
named_scope :food, :conditions => { :type => "food" }
end

# Rails 3
class Product
scope :food, where(:type => "food")
end
</pre>

==JavaScript Support<ref>Gadbois 2010</ref>==

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

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

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

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

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

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

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

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Naik, Pratik. "Active Record Query Interface 3.0" http://m.onkey.org/active-record-query-interface , 2010.

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

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

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T19:27:37Z

Mrmanrin: /* Introduction */

=Introduction=
The original Ruby on Rails platform was extracted from the web-based project-management tool called Basecamp developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project. [REFERENCE] Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of Convention over Configuration [WIKI LINK] and Don’t Repeat Yourself (DRY) [WIKI LINK].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades.

===Rails 1.0===
Initially, Rails 1.0 was released 15 months after the original source was made available. [REFERENCE] This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

===Rails 2.0 ===
Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

===Rails 2.3===
The next major update was Rails 2.3 at it was the most structural update prior to Rails 3.0 being released. The two primary changes in the architecture of the Rails application was the complete integration of the Rack modular web server interface and a renewed support for Rails Engines. {link 2} Alongside of these changes were updates to templates, the addition of built-in support for HTTP Digest Authentication, nested forms models, Metal, and improved caching performance among other things.

===Rails 3.0===
Between Rails 2.3 and the release of Rails 3.0, Rails announced that it would merge with Merb and that Rails 3.0 would be the successor to both Rails 2 and Merb. Merb which is short for Mongrel+Erb, key feature that prompted the join Rails was its component modularity, extensible API design, and vertical scalability.

=Rails 2 vs. Rails 3=

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

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

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

==Gem Dependencies==

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

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

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==
Active Record, like all of the core Rails components, got a major overhaul.

===Arel and the Query Interface===
The most prominent changes made that will be apparent to developers will be the integration with [https://github.com/nkallen/arel Arel]. With this integration, all of the core methods for Active Record return relations, allowing them to be chained together to develop complex queries. A full list and their functionality can be found in the [http://guides.rubyonrails.org/active_record_querying.html Rails Guide]. This will take the place of the options hash that would normally get passed in to one of the Active Record methods. To illustrate this, say we wanted to get a list of the first 10 products ordered alphabetically:

<pre>
# Rails 2
Product.find(:order => "name DESC", :limit => 10)

# Rails 3
Product.order("name DESC").limit(10)
</pre>

Also, there are a lot of methods that are losing the options parameter in their definitions<ref>Naik 2010</ref>, including query methods find and all as well as calculation methods count and average. Also, the <tt>:all</tt> and <tt>:first</tt> parameters for the find method are being deprecated in favor of the <tt>all</tt> and <tt>first</tt> methods. Here are some examples of how things are changing:

<pre>
# Changes to the find method.
# Rails 2
Product.find(:all)
Product.find(:first)

# Rails 3
Product.all
Product.first

# Examples of method options being removed.
# Rails 2
Product.all(:joins => :categories)

# Rails 3
Product.joins("categories")
</pre>

===Named Scopes===
The <tt>named_scope</tt> definition has been changed to just <tt>scope</tt>. The options hash is also being deprecated and should be replaced with the new methods provided by the Arel integration. Translating existing Rails 2 named scopes is easy enough:

<pre>
# Rails 2
class Product
named_scope :food, :conditions => { :type => "food" }
end

# Rails 3
class Product
scope :food, where(:type => "food")
end
</pre>

==JavaScript Support<ref>Gadbois 2010</ref>==

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

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

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

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

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

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

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

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Naik, Pratik. "Active Record Query Interface 3.0" http://m.onkey.org/active-record-query-interface , 2010.

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

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

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T04:20:36Z

Mrmanrin: /* Rails 2 vs. Rails 3 */

=Introduction=
The original Ruby on Rail platform was extracted from the web-based project-management tool called Basecamp developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project. [REFERENCE] Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of Convention over Configuration [WIKI LINK] and Don’t Repeat Yourself (DRY) [WIKI LINK].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades. Initially, Rails 1.0 was released 15 months after the original source was made available. [REFERENCE] This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

The next major update before Rails 3.0 was Rails 2.3 at it was the most substantial update thus far…. not finished..

=Rails 2 vs. Rails 3=

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

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

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

==Gem Dependencies==

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

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

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==
Active Record, like all of the core Rails components, got a major overhaul.

===Arel and the Query Interface===
The most prominent changes made that will be apparent to developers will be the integration with [https://github.com/nkallen/arel Arel]. With this integration, all of the core methods for Active Record return relations, allowing them to be chained together to develop complex queries. A full list and their functionality can be found in the [http://guides.rubyonrails.org/active_record_querying.html Rails Guide]. This will take the place of the options hash that would normally get passed in to one of the Active Record methods. To illustrate this, say we wanted to get a list of the first 10 products ordered alphabetically:

<pre>
# Rails 2
Product.find(:order => "name DESC", :limit => 10)

# Rails 3
Product.order("name DESC").limit(10)
</pre>

Also, there are a lot of methods that are losing the options parameter in their definitions<ref>Naik 2010</ref>, including query methods find and all as well as calculation methods count and average. Also, the <tt>:all</tt> and <tt>:first</tt> parameters for the find method are being deprecated in favor of the <tt>all</tt> and <tt>first</tt> methods. Here are some examples of how things are changing:

<pre>
# Changes to the find method.
# Rails 2
Product.find(:all)
Product.find(:first)

# Rails 3
Product.all
Product.first

# Examples of method options being removed.
# Rails 2
Product.all(:joins => :categories)

# Rails 3
Product.joins("categories")
</pre>

===Named Scopes===
The <tt>named_scope</tt> definition has been changed to just <tt>scope</tt>. The options hash is also being deprecated and should be replaced with the new methods provided by the Arel integration. Translating existing Rails 2 named scopes is easy enough:

<pre>
# Rails 2
class Product
named_scope :food, :conditions => { :type => "food" }
end

# Rails 3
class Product
scope :food, where(:type => "food")
end
</pre>

==JavaScript Support<ref>Gadbois 2010</ref>==

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

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

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

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

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

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

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

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Naik, Pratik. "Active Record Query Interface 3.0" http://m.onkey.org/active-record-query-interface , 2010.

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

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

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T04:19:47Z

Mrmanrin: /* Full Reference Information */

=Introduction=
The original Ruby on Rail platform was extracted from the web-based project-management tool called Basecamp developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project. [REFERENCE] Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of Convention over Configuration [WIKI LINK] and Don’t Repeat Yourself (DRY) [WIKI LINK].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades. Initially, Rails 1.0 was released 15 months after the original source was made available. [REFERENCE] This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

The next major update before Rails 3.0 was Rails 2.3 at it was the most substantial update thus far…. not finished..

=Rails 2 vs. Rails 3=

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

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

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

==Gem Dependencies==

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

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

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==
Active Record, like all of the core Rails components, got a major overhaul.

===Arel and the Query Interface===
The most prominent changes made that will be apparent to developers will be the integration with [https://github.com/nkallen/arel Arel]. With this integration, all of the core methods for Active Record return relations, allowing them to be chained together to develop complex queries. A full list and their functionality can be found in the [http://guides.rubyonrails.org/active_record_querying.html Rails Guide]. This will take the place of the options hash that would normally get passed in to one of the Active Record methods. To illustrate this, say we wanted to get a list of the first 10 products ordered alphabetically:

<pre>
# Rails 2
Product.find(:order => "name DESC", :limit => 10)

# Rails 3
Product.order("name DESC").limit(10)
</pre>

Also, there are a lot of methods that are losing the options parameter in their definitions<ref>Naik 2010</ref>, including query methods find and all as well as calculation methods count and average. Also, the <tt>:all</tt> and <tt>:first</tt> parameters for the find method are being deprecated in favor of the <tt>all</tt> and <tt>first</tt> methods. Here are some examples of how things are changing:

<pre>
# Changes to the find method.
# Rails 2
Product.find(:all)
Product.find(:first)

# Rails 3
Product.all
Product.first

# Examples of method options being removed.
# Rails 2
Product.all(:joins => :categories)

# Rails 3
Product.joins("categories")
</pre>

===Named Scopes===
The <tt>named_scope</tt> definition has been changed to just <tt>scope</tt>. The options hash is also being deprecated and should be replaced with the new methods provided by the Arel integration. Translating existing Rails 2 named scopes is easy enough:

<pre>
# Rails 2
class Product
named_scope :food, :conditions => { :type => "food" }
end

# Rails 3
class Product
scope :food, where(:type => "food")
end
</pre>

==JavaScript Support<ref>Gadbois 2010</ref>==

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

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

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

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

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

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

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

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Naik, Pratik. "Active Record Query Interface 3.0" http://m.onkey.org/active-record-query-interface , 2010.

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

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

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T04:18:46Z

Mrmanrin: /* Arel and the Query Interface */

=Introduction=
The original Ruby on Rail platform was extracted from the web-based project-management tool called Basecamp developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project. [REFERENCE] Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of Convention over Configuration [WIKI LINK] and Don’t Repeat Yourself (DRY) [WIKI LINK].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades. Initially, Rails 1.0 was released 15 months after the original source was made available. [REFERENCE] This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

The next major update before Rails 3.0 was Rails 2.3 at it was the most substantial update thus far…. not finished..

=Rails 2 vs. Rails 3=

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

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

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

==Gem Dependencies==

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

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

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==
Active Record, like all of the core Rails components, got a major overhaul.

===Arel and the Query Interface===
The most prominent changes made that will be apparent to developers will be the integration with [https://github.com/nkallen/arel Arel]. With this integration, all of the core methods for Active Record return relations, allowing them to be chained together to develop complex queries. A full list and their functionality can be found in the [http://guides.rubyonrails.org/active_record_querying.html Rails Guide]. This will take the place of the options hash that would normally get passed in to one of the Active Record methods. To illustrate this, say we wanted to get a list of the first 10 products ordered alphabetically:

<pre>
# Rails 2
Product.find(:order => "name DESC", :limit => 10)

# Rails 3
Product.order("name DESC").limit(10)
</pre>

Also, there are a lot of methods that are losing the options parameter in their definitions<ref>Naik 2010</ref>, including query methods find and all as well as calculation methods count and average. Also, the <tt>:all</tt> and <tt>:first</tt> parameters for the find method are being deprecated in favor of the <tt>all</tt> and <tt>first</tt> methods. Here are some examples of how things are changing:

<pre>
# Changes to the find method.
# Rails 2
Product.find(:all)
Product.find(:first)

# Rails 3
Product.all
Product.first

# Examples of method options being removed.
# Rails 2
Product.all(:joins => :categories)

# Rails 3
Product.joins("categories")
</pre>

===Named Scopes===
The <tt>named_scope</tt> definition has been changed to just <tt>scope</tt>. The options hash is also being deprecated and should be replaced with the new methods provided by the Arel integration. Translating existing Rails 2 named scopes is easy enough:

<pre>
# Rails 2
class Product
named_scope :food, :conditions => { :type => "food" }
end

# Rails 3
class Product
scope :food, where(:type => "food")
end
</pre>

==JavaScript Support<ref>Gadbois 2010</ref>==

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

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

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

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

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

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

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

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

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

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T04:16:56Z

Mrmanrin: /* Active Record */

=Introduction=
The original Ruby on Rail platform was extracted from the web-based project-management tool called Basecamp developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project. [REFERENCE] Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of Convention over Configuration [WIKI LINK] and Don’t Repeat Yourself (DRY) [WIKI LINK].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades. Initially, Rails 1.0 was released 15 months after the original source was made available. [REFERENCE] This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

The next major update before Rails 3.0 was Rails 2.3 at it was the most substantial update thus far…. not finished..

=Rails 2 vs. Rails 3=

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

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

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

==Gem Dependencies==

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

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

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==
Active Record, like all of the core Rails components, got a major overhaul.

===Arel and the Query Interface===
The most prominent changes made that will be apparent to developers will be the integration with Arel. With this integration, all of the core methods for Active Record return relations, allowing them to be chained together to develop complex queries. A full list and their functionality can be found in the [http://guides.rubyonrails.org/active_record_querying.html Rails Guide]. This will take the place of the options hash that would normally get passed in to one of the Active Record methods. To illustrate this, say we wanted to get a list of the first 10 products ordered alphabetically:

<pre>
# Rails 2
Product.find(:order => "name DESC", :limit => 10)

# Rails 3
Product.order("name DESC").limit(10)
</pre>

Also, there are a lot of methods that are losing the options parameter in their definitions<ref>Naik 2010</ref>, including query methods find and all as well as calculation methods count and average. Also, the <tt>:all</tt> and <tt>:first</tt> parameters for the find method are being deprecated in favor of the <tt>all</tt> and <tt>first</tt> methods. Here are some examples of how things are changing:

<pre>
# Changes to the find method.
# Rails 2
Product.find(:all)
Product.find(:first)

# Rails 3
Product.all
Product.first

# Examples of method options being removed.
# Rails 2
Product.all(:joins => :categories)

# Rails 3
Product.joins("categories")
</pre>

===Named Scopes===
The <tt>named_scope</tt> definition has been changed to just <tt>scope</tt>. The options hash is also being deprecated and should be replaced with the new methods provided by the Arel integration. Translating existing Rails 2 named scopes is easy enough:

<pre>
# Rails 2
class Product
named_scope :food, :conditions => { :type => "food" }
end

# Rails 3
class Product
scope :food, where(:type => "food")
end
</pre>

==JavaScript Support<ref>Gadbois 2010</ref>==

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

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

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

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

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

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

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

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

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

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T03:28:56Z

Mrmanrin:

=Introduction=
The original Ruby on Rail platform was extracted from the web-based project-management tool called Basecamp developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project. [REFERENCE] Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of Convention over Configuration [WIKI LINK] and Don’t Repeat Yourself (DRY) [WIKI LINK].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades. Initially, Rails 1.0 was released 15 months after the original source was made available. [REFERENCE] This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

The next major update before Rails 3.0 was Rails 2.3 at it was the most substantial update thus far…. not finished..

=Rails 2 vs. Rails 3=

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

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

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

==Gem Dependencies==

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

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

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==

===Active Model===

==JavaScript Support<ref>Gadbois 2010</ref>==

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

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

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

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

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

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

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

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

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

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T03:28:05Z

Mrmanrin: /* Full Reference Information */

=Introduction=
The original Ruby on Rail platform was extracted from the web-based project-management tool called Basecamp developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project. [REFERENCE] Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of Convention over Configuration [WIKI LINK] and Don’t Repeat Yourself (DRY) [WIKI LINK].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades. Initially, Rails 1.0 was released 15 months after the original source was made available. [REFERENCE] This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

The next major update before Rails 3.0 was Rails 2.3 at it was the most substantial update thus far…. not finished..

=Rails 2 vs. Rails 3=

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

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

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

==Gem Dependencies==

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

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

==Action Controller==

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==

===Active Model===

==JavaScript Support<ref>Gadbois 2010</ref>==

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

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

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

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

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

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

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

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

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

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T03:27:09Z

Mrmanrin: /* Full Reference Information */

=Introduction=
The original Ruby on Rail platform was extracted from the web-based project-management tool called Basecamp developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project. [REFERENCE] Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of Convention over Configuration [WIKI LINK] and Don’t Repeat Yourself (DRY) [WIKI LINK].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades. Initially, Rails 1.0 was released 15 months after the original source was made available. [REFERENCE] This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

The next major update before Rails 3.0 was Rails 2.3 at it was the most substantial update thus far…. not finished..

=Rails 2 vs. Rails 3=

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

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

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

==Gem Dependencies==

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

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

==Action Controller==

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==

===Active Model===

==JavaScript Support<ref>Gadbois 2010</ref>==

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

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

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

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

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

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

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

RailsGuides. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html ,

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

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

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T02:26:23Z

Mrmanrin: /* RESTful Resources */

=Introduction=
The original Ruby on Rail platform was extracted from the web-based project-management tool called Basecamp developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project. [REFERENCE] Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of Convention over Configuration [WIKI LINK] and Don’t Repeat Yourself (DRY) [WIKI LINK].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades. Initially, Rails 1.0 was released 15 months after the original source was made available. [REFERENCE] This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

The next major update before Rails 3.0 was Rails 2.3 at it was the most substantial update thus far…. not finished..

=Rails 2 vs. Rails 3=

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

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

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

==Gem Dependencies==

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

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

==Action Controller==

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==

===Active Model===

==JavaScript Support<ref>Gadbois 2010</ref>==

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

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

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

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

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

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

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

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

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

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T02:18:14Z

Mrmanrin: /* Full Reference Information */

=Introduction=
The original Ruby on Rail platform was extracted from the web-based project-management tool called Basecamp developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project. [REFERENCE] Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of Convention over Configuration [WIKI LINK] and Don’t Repeat Yourself (DRY) [WIKI LINK].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades. Initially, Rails 1.0 was released 15 months after the original source was made available. [REFERENCE] This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

The next major update before Rails 3.0 was Rails 2.3 at it was the most substantial update thus far…. not finished..

=Rails 2 vs. Rails 3=

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

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

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

==Gem Dependencies==

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

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

==Action Controller==

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===

==Active Record==

===Active Model===

==JavaScript Support<ref>Gadbois 2010</ref>==

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

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

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

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

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

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

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

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

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

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T02:17:06Z

Mrmanrin: /* Routing DSL */

=Introduction=
The original Ruby on Rail platform was extracted from the web-based project-management tool called Basecamp developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project. [REFERENCE] Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of Convention over Configuration [WIKI LINK] and Don’t Repeat Yourself (DRY) [WIKI LINK].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades. Initially, Rails 1.0 was released 15 months after the original source was made available. [REFERENCE] This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

The next major update before Rails 3.0 was Rails 2.3 at it was the most substantial update thus far…. not finished..

=Rails 2 vs. Rails 3=

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

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

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

==Gem Dependencies==

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

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

==Action Controller==

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===

==Active Record==

===Active Model===

==JavaScript Support<ref>Gadbois 2010</ref>==

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

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

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

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

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

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

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

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

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-21T04:33:47Z

Mrmanrin: /* Full Reference Information */

=Introduction=

=Rails 2 vs. Rails 3=

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

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

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

==Gem Dependencies==

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

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

==Action Controller==

==Routing DSL==

==Active Record==

===Active Model===

==JavaScript Support<ref>Gadbois 2010</ref>==

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

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

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

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

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

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

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

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

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-21T04:31:29Z

Mrmanrin: /* JavaScript Libraries */

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-21T04:12:55Z

Mrmanrin:

=Introduction=

=Rails 2 vs. Rails 3=

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

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

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

==Gem Dependencies==

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

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

==Action Controller==

==Routing DSL==

==Active Record==

===Active Model===

==JavaScript Libraries==

There are many JavaScript libraries available to programmers to make their web applications more dynamic and smooth looking. Whenever you created a Rails 2 application, it would automatically install the Prototype framework. As of Rails 3.1, the jQuery framework has replaced Prototype as the default JavaScript framework. Programmers that wish to still use Prototype must remember to specify this when they create the Rails application.

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

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

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-21T04:05:01Z

Mrmanrin:

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-21T03:56:00Z

Mrmanrin:

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-21T03:45:49Z

Mrmanrin:

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-21T03:36:54Z

Mrmanrin:

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-20T23:48:29Z

Mrmanrin: Created page with "=Introduction="

=Introduction=