Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T21:54:18Z

Nmsarda:

<h1>SaaS - 3.7. Mixins and Duck Typing</h1>
This wiki is aimed at acting as a complementary read to the [http://www.youtube.com/watch?v=Q1h-W0sWVoM SaaS - 3.7. Mixins and Duck Typing lecture][1]. This lecture describes three of the most important fundamentals of the Ruby language: Duck-Typing, Modules and Mixins.
<h1>Introduction</h1>
*Duck-typing is one of the main features of many object-oriented languages. Duck-Typing describes how a language like Ruby, treats its objects as compared to a language like JAVA. We describe the beautiful features of Duck-typing and also its negative side-effects.<br>
*Modules define a namespace. It provides a mechanism to club several things together which naturally do-not form a common class. With modules, programmer does not have to worry of possible name-clashes of method name's with other methods written by different programmers. Modules handles this by making use of namespace.<br>
*Mixins extend from modules. modules are not classes and hence we cannot instantiate them. However, when modules are 'include'ed in a class, all its methods are available to that class. We say modules are 'mixed in' to the class or in other words 'mixins'. Modules which are mixed in behave as superclass and provide multiple inheritance.

<h1>[http://en.wikipedia.org/wiki/Duck_typing Duck Typing][2]</h1>
<h2>What is Duck Typing</h2>
'''“If a object walks like a duck, quacks like a duck then treat it as a duck”'''

[[File:Dtype.png|frame|left|[http://www.codecapers.com/post/Duck-Typing.aspx A cat or a duck or a cat walking like a duck?][3]]]
<br><br><br><br><br>This is the ‘mantra’ of Ruby language and the most pleasing aspect of the language. What it means is that, whether an object responds to a method?, is only important and not the type of the object.
If a dragon responds to methods like swim and quacking, ruby is happy to treat dragon as a duck without having a concern of whether it actually is a duck or not. This gives powerful tools for a ruby programmer.

This is possible in Ruby because we don’t declare the '[http://en.wikipedia.org/wiki/Programming_language#Type_system Type][4] of variables or methods like in JAVA; in Ruby, everything is an object and each object can be individually modified, irrespective of its implementation in the class to which it belongs.
<br>

<br><br><br><br>
Consider the following example taken from the SAAS lecture:
<pre>
my_list.sort

[5, 4, 3].sort
["dog", "cat", "rat"].sort
[:a, :b, :c].sort
</pre>

Here, the same function, sort, is responding to an array of integers, strings and literals. This is classic Ruby duck-typing at work. How sort works is that it compares the elements which are needed to be sorted. So as long as the elements can be compared, sort function works. In the above example, the array of integers, strings and literals implement the comparison operator and hence the same sort function works for all of them.

<h2> Why in Ruby and not in JAVA? </h2>
The reason for duck-typing to be easily possible and implemented in language like Ruby and not in language like JAVA is that these 2 languages treat ‘type’ differently.
In JAVA or C++, type means class. When someone asks the type of “abc”, we say it is String. So, such language allows String objects to refer to only other String objects.
String a; a will never be allowed to refer to anything other than a string, like a=5.

While in Ruby, type refers to how the object reacts to a method or in other words does the object have a particular capability. Type refers to this capability. While a class to which the object belongs provides the initial capabilities, from that point on, the object is free to extend its capabilities independently of its pre-defined class. So,

a= ”abc”
a= 5 are two perfectly acceptable statements in Ruby.

This is duck-typing.
[http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/ A classic example][5] of how a scripting language, JavaScript, not implementing duck-typing can lead to some bad code.

<h2> Duck-Typing in action</h2>
<pre>
class American
def football
puts "We play it with hands"
end

end

class European
def football
puts "We play it with legs"
end
end

class Martian
end

footballManiac = [American.new,European.new]

footballManiac.each {|game| game.football}
</pre>

Output of this program is We play it with hands(next line) We play it with legs

This is because of duck-typing. footballManiac first acted as an American class object and since that class responded to the football method, it executed it. Then it acted as an European class object and again that class responded to the method, it executed it. In static-typed languages, we would have to type cast each object and even then we might get compile time or run time error. Nothing of that sorts in Ruby. Now let us also create a Martian class object.

<pre>
footballManiac = [American.new,European.new,Martian.new]

footballManiac.each {|game| game.football}
</pre>

On executing it, we get the following error
<pre>undefined method `football' for #<Martian:0x3425358> (NoMethodError)</pre>
This is obvious because martians do not play football. But the point is, Ruby still checked the martian class and when it found that the object does not respond to the method, it complained.

<h2> The other side to Duck-Typing </h2>
As with everything in life, there is always 2 perspectives about its usefulness. Following are some of the criticism against duck-typing :
<h3>Lack of compiler security</h3>
There is no help from compiler for a programmer error like assigning a string to an integer and so on. Only when you run the code, the output might be funny and that’s when you realize a probable mistake in assignment. In a static-type language, there is always a compiler check and hence the problem does not arise. Obviously this problem can be alleviated by proper and exhaustive testing. But as we all know, no one can guarantee 100% code tests.
<h3>Contract between caller and the callee</h3>
In a static type language, the caller knows the exact ‘type’ of parameters required by the callee and also the return-type from the callee. In dynamic type languages, no type is provided. So to understand what the callee expects, one has to look at the code and understand. This is difficult in most of the cases and mainly for third-party code. Again this problem can be solved by providing proper documentation of each API and the pre-requirements for execution. But who can guarantee that the documents correctly map the requirements?

<h1>Modules and Mixins</h1>
<h2>What are modules and mixins?</h2>
In Ruby language modules facilitate grouping of classes, methods and constants. A module has been defined as collection of classes and instance methods but they are not a class so they can’t be instantiated. However, modules can be mixed-in a class. The implementation of module is intertwined with that of a class thus providing the functionality of a module to given class. Modules provide a namespace which prevents name clashes and implementation of mixin facility.

The namespace facility is used when a class requires two methods from different classes having the same name. The class does not have the ability to recognize the methods independently which leads to name clashes. Consider the following example where Math module defines sin method and Action module defines sin method as well.

<pre>
module Math
PI = 3.141592654
def Math.sin(x)
#.....
end
end

module Action
BAD = -1
def Action.sin(badness)
#.....
end
end
</pre>

By implementing sin methods in different modules eliminates name clashes since the methods will now be referenced in a class which includes these modules. The modules can be included in a class using the require statement, this is shown as follows:

<pre>
require Math
require Action

sinValue = Math.sin(Math::PI/2)
bad_action = Action.sin(Action::BAD)
</pre>

[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Module methods][6] are invoked in the same manner as class methods by preceding its name with the module's name and a period, and by referencing a constant using the module name and two colons.

<h2>[http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby Types of mixins][7]</h2>
The following example demonstrates two types of mixins. Consider the following example of a module,
<pre>
module Example

def example
if @variable > 0
return 1
else
return 0
end

end
</pre>
The Example module makes use of @variable instance variable. The class which mixes this module has to define the @variable since the Example module makes use of @variable but does not define it. A module can make use of methods not defined within the module but the class in which it has been mixed in. Thus, this module exhibits dependency on the implementation of the class it is mixed with.

The following example demonstrates an independent module ,
<pre>
module AddSub

#Class method
def add(var_one, var_two)
SampleClass.new(var_one + var_two)
end

end
</pre>

The Addition module defines a class method as well as an instance method. Class methods are also known as static methods. The add method in the AddSub module defines accepts two integers and returns an instance of SampleClass. The mixin SampleClass class is defined as follows:

<pre>
# Base Integer class
Class Integer
def value
@variable
end
end

# SampleClass extends Integer
class SampleClass < Integer

# Add instance methods from Example
include Stringify

# Add class methods from AddSub
extend AddSub

# Add a constructor with one parameter
def initialize(value)
@variable = value
end
end
</pre>

The module methods have been mixed into the class using the include and extend methods respectively. The extend method will mix the methods as class/static methods.
<pre>
#Call class method from AddSub module

object1 = SampleClass.add(2,3)
puts object1.value # -> 5
</pre>

The include method will mix the methods defined in the module as instance methods.
<pre>
#Call instance method from Example module

puts object1.example # -> 1
</pre>
However, care must be taken that including an instance method does not copy the module's instance methods into the class. A reference is generated from the class to the included module. This applies to all the classes which have included the module. If any change is made in the
instance method it will be reflected in the behavior of all the classes that include the
module.
The extend method comes with an additional feature. An object instance can be enhanced at run time by mixing it in a module at run time.

<pre>
module ScaleValue
def multiply
“#{@variable}*100”
end
end
</pre>

An object instance can be extended with a module using the following commands:
<pre>
#Adding module methods to this object instance only!

object1.extend ScaleValue
puts object1.multiply # -> 500
</pre>

The extend method includes the module methods only on object1, the remaining objects will not this functionality.

<pre>
puts object2.multiple # generate error
</pre>

<h2>Mix-in is a contract</h2>
The Enumerable module provides various methods as a mixin to a given class. However, the module assumes that all the objects of a given class respond to <i>each</i> method. Apart from this, Enumerable provides methods which can be used to query an object whether it responds to a given method or not. Given the ability of an object to respond to <i>each</i> method which iterates over the collection of elements one can make use of following methods to find out the properties of an object. Some of the methods Enumerable provides are as follows:

• all?, any?, collect, find, include?, inject, map, and partition

In Java one can find the declaration “Array implements Enumerable”, no such declaration is found in Ruby. The reason being the methods in Enumerable module assume that the target objects are capable of responding to the methods invoked on them.

Comparable is another module which assumes that objects of a given class respond to < = > (spaceship) operator. Similar to the Enumerable module, Comparable provides various methods for comparing the objects and some of them are mentioned below:

• <, <=, >, >=, ==, and between?

Given a class which implements spaceship operator and <i>each</i> method, the objects can make use of sort method which requires implementation of spaceship operator so that the objects are capable to comparing with each other and the <i>each</i> method in order to retrieve the objects one at a time. By mixing modules within a class, an object can perform various actions such as map, reduce, and many more. The classes do not matter unless they respond to certain methods. Consider an example of constructing a data structure, by implementing <i>each</i> method the data structure can implement various methods such as sort, map, reduce etc in its own way. Thus, mixing modules facilitate behavior reuse which is an added advantage.

The video lecture presents an example of Account class which implements spaceship operator.
The spaceship operator is used to compare the balance of two different objects.

<pre>
class Account
include Comparable
def <=>(other)
self.balance <=> other.balance
end
end

</pre>

On defining the spaceship operator the objects of Account class can define of all the other methods Comparable module provides. In this manner the Account class takes advantage of behavior reuse.

<h1> Conclusion </h1>
Duck typing is a very powerful tool in the hands of the programmer and it increases the speed of production. If used wisely, it is a boon. But if written in a non-sensical manner, then tracking errors becomes difficult and one has to trace the code to find out the errors. Modules provide a great way to stuff in the non-related or related code under one namespace and when it is mixed-in to a class, it acts as a superclass providing a path to do multiple inheritance, if the need be.

<h1>References</h1>
*[1] http://www.youtube.com/watch?v=Q1h-W0sWVoM
*[2] http://en.wikipedia.org/wiki/Duck_typing
*[3] http://www.codecapers.com/post/Duck-Typing.aspx
*[4] http://en.wikipedia.org/wiki/Programming_language#Type_system
*[5] http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/
*[6] http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html
*[7] http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/

<h1>Additional Reading</h1>
* Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
* [http://beust.com/weblog/2005/04/15/the-perils-of-duck-typing/ Perils of Duck Typing]
* [http://stackoverflow.com/questions/4205130/what-is-duck-typing What is Duck Typing : Stack Overflow]
* [http://en.wikipedia.org/wiki/Type_system What actually do you mean by 'Type']

CSC/ECE 517 Fall 2012

2012-11-18T21:33:19Z

Nmsarda:

*[[CSC/ECE_517_Fall_2012/Table_Of_Contents]]
*[[CSC/ECE 517 Fall 2012/ch1 n xx]]
*[[CSC/ECE 517 Fall 2012/ch1 1w1 rk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w20 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w5 su]]
*[[CSC/ECE 517 Fall 2012/ch1 1w6 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w4 aj]]
*[[CSC/ECE 517 Fall 2012/ch1 1w7 am]]
*[[CSC/ECE 517 Fall 2012/ch1 1w8 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w9 av]]
*[[CSC/ECE 517 Fall 2012/ch1 1w10 pk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w11 ap]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w12 mv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w14 gv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w17 ir]]
*[[CSC/ECE 517 Fall 2012/ch1 1w18 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w22 an]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 wi]]
*[[CSC/ECE 517 Fall 2012/ch1 1w31 sa]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w16 br]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w23 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w24 nr]]
*[[CSC/ECE 517 Fall 2012/ch1 1w15 rt]]
*[[CSC/ECE 517 Fall 2012/ch1 1w3 pl]]
*[[CSC/ECE 517 Fall 2012/ch1 1w32 cm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w37 ss]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w67 ks]]

*[[CSC/ECE 517 Fall 2012/ch1 1w27 ms]]
*[[CSC/ECE 517 Fall 2012/ch1 1w29 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w33 op]]
*[[CSC/ECE 517 Fall 2012/ch1 1w19 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w34 vd]]
*[[CSC/ECE 517 Fall 2012/ch1 1w35 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w30 rp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w58 am]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w47 sk]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w69 mv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w44 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w45 is]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w53 kc]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 ar]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w39 sn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w54 go]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w56 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w64 nn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w66 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w42 js]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w46 sm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w71 gs]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w63 dv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w55 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w57 mp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w52 an]]
*[[CSC/ECE_517_Fall_2012/ch1b 1w38 nm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w60 ac]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w62 rb]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w29 st]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w3_sm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w30 an]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w17 pt]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w31 up]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w9 ms]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w19 is]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w26 aj]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w16 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w8 vp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w18 as]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w3 jm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w23 sr]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w11_aa]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w15 rr]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w33 pv]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w20_aa]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w14_bb]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w21_ap]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w13_sm]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w4_sa]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w25_nr]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w12_sv]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w7_ma]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w6_ar]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w32_mk]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w10_rc]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w70_sm]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w67_sk]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w40_sn]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w22_sk]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w-1w65_am]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w59_bc]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w60_ns]]
*[[CSC/ECE 517 Fall 2012/ch2b 2w47 am]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w69_as]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w39_ka]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w36_av]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w37_ms]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w43_iv]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w53_iv]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w63_sp]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w49_ps]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w52_sj]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w28_dh]]
*[[CSC/ECE 517 Fall 2012/ch1b 2w41 dc]]
*[[CSC/ECE_517_Fall_2012/ch2b_1w59_nm]]

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T21:31:52Z

Nmsarda:

<h1>SaaS - 3.7. Mixins and Duck Typing</h1>
This wiki is aimed at acting as a complementary read to the [http://www.youtube.com/watch?v=Q1h-W0sWVoM SaaS - 3.7. Mixins and Duck Typing lecture][1]. This lecture describes three of the most important fundamentals of the Ruby language: Duck-Typing, Modules and Mixins.
<h1>Introduction</h1>
*Duck-typing is one of the main features of many object-oriented languages. Duck-Typing describes how a language like Ruby, treats its objects as compared to a language like JAVA. We describe the beautiful features of Duck-typing and also its negative side-effects.<br>
*Modules define a namespace. It provides a mechanism to club several things together which naturally do-not form a common class. With modules, programmer does not have to worry of possible name-clashes of method name's with other methods written by different programmers. Modules handles this by making use of namespace.<br>
*Mixins extend from modules. modules are not classes and hence we cannot instantiate them. However, when modules are 'include'ed in a class, all its methods are available to that class. We say modules are 'mixed in' to the class or in other words 'mixins'. Modules which are mixed in behave as superclass and provide multiple inheritance.

<h1>[http://en.wikipedia.org/wiki/Duck_typing Duck Typing][2]</h1>
<h2>What is Duck Typing</h2>
'''“If a object walks like a duck, quacks like a duck then treat it as a duck”'''

[[File:Dtype.png|frame|left|[http://www.codecapers.com/post/Duck-Typing.aspx A cat or a duck or a cat walking like a duck?][3]]]
<br><br><br><br><br>This is the ‘mantra’ of Ruby language and the most pleasing aspect of the language. What it means is that, whether an object responds to a method?, is only important and not the type of the object.
If a dragon responds to methods like swim and quacking, ruby is happy to treat dragon as a duck without having a concern of whether it actually is a duck or not. This gives powerful tools for a ruby programmer.

This is possible in Ruby because we don’t declare the '[http://en.wikipedia.org/wiki/Programming_language#Type_system Type][4] of variables or methods like in JAVA; in Ruby, everything is an object and each object can be individually modified, irrespective of its implementation in the class to which it belongs.
<br>

<br><br><br><br>
Consider the following example taken from the SAAS lecture:
<pre>
my_list.sort

[5, 4, 3].sort
["dog", "cat", "rat"].sort
[:a, :b, :c].sort
</pre>

Here, the same function, sort, is responding to an array of integers, strings and literals. This is classic Ruby duck-typing at work. How sort works is that it compares the elements which are needed to be sorted. So as long as the elements can be compared, sort function works. In the above example, the array of integers, strings and literals implement the comparison operator and hence the same sort function works for all of them.

<h2> Why in Ruby and not in JAVA? </h2>
The reason for duck-typing to be easily possible and implemented in language like Ruby and not in language like JAVA is that these 2 languages treat ‘type’ differently.
In JAVA or C++, type means class. When someone asks the type of “abc”, we say it is String. So, such language allows String objects to refer to only other String objects.
String a; a will never be allowed to refer to anything other than a string, like a=5.

While in Ruby, type refers to how the object reacts to a method or in other words does the object have a particular capability. Type refers to this capability. While a class to which the object belongs provides the initial capabilities, from that point on, the object is free to extend its capabilities independently of its pre-defined class. So,

a= ”abc”
a= 5 are two perfectly acceptable statements in Ruby.

This is duck-typing.
[http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/ A classic example][5] of how a scripting language, JavaScript, not implementing duck-typing can lead to some bad code.

<h2> Duck-Typing in action</h2>
<pre>
class American
def football
puts "We play it with hands"
end

end

class European
def football
puts "We play it with legs"
end
end

class Martian
end

footballManiac = [American.new,European.new]

footballManiac.each {|game| game.football}
</pre>

Output of this program is We play it with hands(next line) We play it with legs

This is because of duck-typing. footballManiac first acted as an American class object and since that class responded to the football method, it executed it. Then it acted as an European class object and again that class responded to the method, it executed it. In static-typed languages, we would have to type cast each object and even then we might get compile time or run time error. Nothing of that sorts in Ruby. Now let us also create a Martian class object.

<pre>
footballManiac = [American.new,European.new,Martian.new]

footballManiac.each {|game| game.football}
</pre>

On executing it, we get the following error
<pre>undefined method `football' for #<Martian:0x3425358> (NoMethodError)</pre>
This is obvious because martians do not play football. But the point is, Ruby still checked the martian class and when it found that the object does not respond to the method, it complained.

<h2> The other side to Duck-Typing </h2>
As with everything in life, there is always 2 perspectives about its usefulness. Following are some of the criticism against duck-typing :
<h3>Lack of compiler security</h3>
There is no help from compiler for a programmer error like assigning a string to an integer and so on. Only when you run the code, the output might be funny and that’s when you realize a probable mistake in assignment. In a static-type language, there is always a compiler check and hence the problem does not arise. Obviously this problem can be alleviated by proper and exhaustive testing. But as we all know, no one can guarantee 100% code tests.
<h3>Contract between caller and the callee</h3>
In a static type language, the caller knows the exact ‘type’ of parameters required by the callee and also the return-type from the callee. In dynamic type languages, no type is provided. So to understand what the callee expects, one has to look at the code and understand. This is difficult in most of the cases and mainly for third-party code. Again this problem can be solved by providing proper documentation of each API and the pre-requirements for execution. But who can guarantee that the documents correctly map the requirements?

<h1>Modules and Mixins</h1>
<h2>What are modules and mixins?</h2>
In Ruby language modules facilitate grouping of classes, methods and constants. A module has been defined as collection of classes and instance methods but they are not a class so they can’t be instantiated. However, modules can be mixed-in a class. The implementation of module is intertwined with that of a class thus providing the functionality of a module to given class. Modules provide a namespace which prevents name clashes and implementation of mixin facility.

The namespace facility is used when a class requires two methods from different classes having the same name. The class does not have the ability to recognize the methods independently which leads to name clashes. Consider the following example where Math module defines sin method and Action module defines sin method as well.

<pre>
module Math
PI = 3.141592654
def Math.sin(x)
#.....
end
end

module Action
BAD = -1
def Action.sin(badness)
#.....
end
end
</pre>

By implementing sin methods in different modules eliminates name clashes since the methods will now be referenced in a class which includes these modules. The modules can be included in a class using the require statement, this is shown as follows:

<pre>
require Math
require Action

sinValue = Math.sin(Math::PI/2)
bad_action = Action.sin(Action::BAD)
</pre>

[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Module methods][6] are invoked in the same manner as class methods by preceding its name with the module's name and a period, and by referencing a constant using the module name and two colons.

<h2>[http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby Types of mixins][7]</h2>
The following example demonstrates two types of mixins. Consider the following example of a module,
<pre>
module Example

def example
if @variable > 0
return 1
else
return 0
end

end
</pre>
The Example module makes use of @variable instance variable. The class which mixes this module has to define the @variable since the Example module makes use of @variable but does not define it. A module can make use of methods not defined within the module but the class in which it has been mixed in. Thus, this module exhibits dependency on the implementation of the class it is mixed with.

The following example demonstrates an independent module ,
<pre>
module AddSub

#Class method
def add(var_one, var_two)
SampleClass.new(var_one + var_two)
end

end
</pre>

The Addition module defines a class method as well as an instance method. Class methods are also known as static methods. The add method in the AddSub module defines accepts two integers and returns an instance of SampleClass. The mixin SampleClass class is defined as follows:

<pre>
# Base Integer class
Class Integer
def value
@variable
end
end

# SampleClass extends Integer
class SampleClass < Integer

# Add instance methods from Example
include Stringify

# Add class methods from AddSub
extend AddSub

# Add a constructor with one parameter
def initialize(value)
@variable = value
end
end
</pre>

The module methods have been mixed into the class using the include and extend methods respectively. The extend method will mix the methods as class/static methods.
<pre>
#Call class method from AddSub module

object1 = SampleClass.add(2,3)
puts object1.value # -> 5
</pre>

The include method will mix the methods defined in the module as instance methods.
<pre>
#Call instance method from Example module

puts object1.example # -> 1
</pre>
However, care must be taken that including an instance method does not copy the module's instance methods into the class. A reference is generated from the class to the included module. This applies to all the classes which have included the module. If any change is made in the
instance method it will be reflected in the behavior of all the classes that include the
module.
The extend method comes with an additional feature. An object instance can be enhanced at run time by mixing it in a module at run time.

<pre>
module ScaleValue
def multiply
“#{@variable}*100”
end
end
</pre>

An object instance can be extended with a module using the following commands:
<pre>
#Adding module methods to this object instance only!

object1.extend ScaleValue
puts object1.multiply # -> 500
</pre>

The extend method includes the module methods only on object1, the remaining objects will not this functionality.

<pre>
puts object2.multiple # generate error
</pre>

<h2>Mix-in is a contract</h2>
The Enumerable module provides various methods as a mixin to a given class. However, the module assumes that all the objects of a given class respond to <i>each</i> method. Apart from this, Enumerable provides methods which can be used to query an object whether it responds to a given method or not. Given the ability of an object to respond to <i>each</i> method which iterates over the collection of elements one can make use of following methods to find out the properties of an object. Some of the methods Enumerable provides are as follows:

• all?, any?, collect, find, include?, inject, map, and partition

In Java one can find the declaration “Array implements Enumerable”, no such declaration is found in Ruby. The reason being the methods in Enumerable module assume that the target objects are capable of responding to the methods invoked on them.

Comparable is another module which assumes that objects of a given class respond to < = > (spaceship) operator. Similar to the Enumerable module, Comparable provides various methods for comparing the objects and some of them are mentioned below:

• <, <=, >, >=, ==, and between?

Given a class which implements spaceship operator and <i>each</i> method, the objects can make use of sort method which requires implementation of spaceship operator so that the objects are capable to comparing with each other and the <i>each</i> method in order to retrieve the objects one at a time. By mixing modules within a class, an object can perform various actions such as map, reduce, and many more. The classes do not matter unless they respond to certain methods. Consider an example of constructing a data structure, by implementing <i>each</i> method the data structure can implement various methods such as sort, map, reduce etc in its own way. Thus, mixing modules facilitate behavior reuse which is an added advantage.

The video lecture presents an example of Account class which implements spaceship operator.
The spaceship operator is used to compare the balance of two different objects.

<pre>
class Account
include Comparable
def <=>(other)
self.balance <=> other.balance
end
end

</pre>

On defining the spaceship operator the objects of Account class can define of all the other methods Comparable module provides. In this manner the Account class takes advantage of behavior reuse.

<h1>References</h1>
*[1] http://www.youtube.com/watch?v=Q1h-W0sWVoM
*[2] http://en.wikipedia.org/wiki/Duck_typing
*[3] http://www.codecapers.com/post/Duck-Typing.aspx
*[4] http://en.wikipedia.org/wiki/Programming_language#Type_system
*[5] http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/
*[6] http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html
*[7] http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/

<h1>Additional Reading</h1>
* Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
* [http://beust.com/weblog/2005/04/15/the-perils-of-duck-typing/ Perils of Duck Typing]
* [http://stackoverflow.com/questions/4205130/what-is-duck-typing What is Duck Typing : Stack Overflow]
* [http://en.wikipedia.org/wiki/Type_system What actually do you mean by 'Type']

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T21:31:11Z

Nmsarda:

<h1>SaaS - 3.7. Mixins and Duck Typing</h1>
This wiki is aimed at acting as a complementary read to the [http://www.youtube.com/watch?v=Q1h-W0sWVoM SaaS - 3.7. Mixins and Duck Typing lecture][1]. This lecture describes three of the most important fundamentals of the Ruby language: Duck-Typing, Modules and Mixins.
<h1>Introduction</h1>
*Duck-typing is one of the main features of many object-oriented languages. Duck-Typing describes how a language like Ruby, treats its objects as compared to a language like JAVA. We describe the beautiful features of Duck-typing and also its negative side-effects.<br>
*Modules define a namespace. It provides a mechanism to club several things together which naturally do-not form a common class. With modules, programmer does not have to worry of possible name-clashes of method name's with other methods written by different programmers. Modules handles this by making use of namespace.<br>
*Mixins extend from modules. modules are not classes and hence we cannot instantiate them. However, when modules are 'include'ed in a class, all its methods are available to that class. We say modules are 'mixed in' to the class or in other words 'mixins'. Modules which are mixed in behave as superclass and provide multiple inheritance.

<h2>Scope</h2>
The scope of this article is limited to the scope covered in video lecture. The lecture starts with an introduction of duck typing where each object takes care of the methods it can handle and modules which facilitate inheritance in Ruby classes. The video lecture illustrates how different classes respond to instance methods by including modules.

Hence for the purpose of this article it is assumed that the reader has already read the relevant material and watched the video lecture.

<h1>[http://en.wikipedia.org/wiki/Duck_typing Duck Typing][2]</h1>
<h2>What is Duck Typing</h2>
'''“If a object walks like a duck, quacks like a duck then treat it as a duck”'''

[[File:Dtype.png|frame|left|[http://www.codecapers.com/post/Duck-Typing.aspx A cat or a duck or a cat walking like a duck?][3]]]
<br><br><br><br><br>This is the ‘mantra’ of Ruby language and the most pleasing aspect of the language. What it means is that, whether an object responds to a method?, is only important and not the type of the object.
If a dragon responds to methods like swim and quacking, ruby is happy to treat dragon as a duck without having a concern of whether it actually is a duck or not. This gives powerful tools for a ruby programmer.

This is possible in Ruby because we don’t declare the '[http://en.wikipedia.org/wiki/Programming_language#Type_system Type][4] of variables or methods like in JAVA; in Ruby, everything is an object and each object can be individually modified, irrespective of its implementation in the class to which it belongs.
<br>

<br><br><br><br>
Consider the following example taken from the SAAS lecture:
<pre>
my_list.sort

[5, 4, 3].sort
["dog", "cat", "rat"].sort
[:a, :b, :c].sort
</pre>

Here, the same function, sort, is responding to an array of integers, strings and literals. This is classic Ruby duck-typing at work. How sort works is that it compares the elements which are needed to be sorted. So as long as the elements can be compared, sort function works. In the above example, the array of integers, strings and literals implement the comparison operator and hence the same sort function works for all of them.

<h2> Why in Ruby and not in JAVA? </h2>
The reason for duck-typing to be easily possible and implemented in language like Ruby and not in language like JAVA is that these 2 languages treat ‘type’ differently.
In JAVA or C++, type means class. When someone asks the type of “abc”, we say it is String. So, such language allows String objects to refer to only other String objects.
String a; a will never be allowed to refer to anything other than a string, like a=5.

While in Ruby, type refers to how the object reacts to a method or in other words does the object have a particular capability. Type refers to this capability. While a class to which the object belongs provides the initial capabilities, from that point on, the object is free to extend its capabilities independently of its pre-defined class. So,

a= ”abc”
a= 5 are two perfectly acceptable statements in Ruby.

This is duck-typing.
[http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/ A classic example][5] of how a scripting language, JavaScript, not implementing duck-typing can lead to some bad code.

<h2> Duck-Typing in action</h2>
<pre>
class American
def football
puts "We play it with hands"
end

end

class European
def football
puts "We play it with legs"
end
end

class Martian
end

footballManiac = [American.new,European.new]

footballManiac.each {|game| game.football}
</pre>

Output of this program is We play it with hands(next line) We play it with legs

This is because of duck-typing. footballManiac first acted as an American class object and since that class responded to the football method, it executed it. Then it acted as an European class object and again that class responded to the method, it executed it. In static-typed languages, we would have to type cast each object and even then we might get compile time or run time error. Nothing of that sorts in Ruby. Now let us also create a Martian class object.

<pre>
footballManiac = [American.new,European.new,Martian.new]

footballManiac.each {|game| game.football}
</pre>

On executing it, we get the following error
<pre>undefined method `football' for #<Martian:0x3425358> (NoMethodError)</pre>
This is obvious because martians do not play football. But the point is, Ruby still checked the martian class and when it found that the object does not respond to the method, it complained.

<h2> The other side to Duck-Typing </h2>
As with everything in life, there is always 2 perspectives about its usefulness. Following are some of the criticism against duck-typing :
<h3>Lack of compiler security</h3>
There is no help from compiler for a programmer error like assigning a string to an integer and so on. Only when you run the code, the output might be funny and that’s when you realize a probable mistake in assignment. In a static-type language, there is always a compiler check and hence the problem does not arise. Obviously this problem can be alleviated by proper and exhaustive testing. But as we all know, no one can guarantee 100% code tests.
<h3>Contract between caller and the callee</h3>
In a static type language, the caller knows the exact ‘type’ of parameters required by the callee and also the return-type from the callee. In dynamic type languages, no type is provided. So to understand what the callee expects, one has to look at the code and understand. This is difficult in most of the cases and mainly for third-party code. Again this problem can be solved by providing proper documentation of each API and the pre-requirements for execution. But who can guarantee that the documents correctly map the requirements?

<h1>Modules and Mixins</h1>
<h2>What are modules and mixins?</h2>
In Ruby language modules facilitate grouping of classes, methods and constants. A module has been defined as collection of classes and instance methods but they are not a class so they can’t be instantiated. However, modules can be mixed-in a class. The implementation of module is intertwined with that of a class thus providing the functionality of a module to given class. Modules provide a namespace which prevents name clashes and implementation of mixin facility.

The namespace facility is used when a class requires two methods from different classes having the same name. The class does not have the ability to recognize the methods independently which leads to name clashes. Consider the following example where Math module defines sin method and Action module defines sin method as well.

<pre>
module Math
PI = 3.141592654
def Math.sin(x)
#.....
end
end

module Action
BAD = -1
def Action.sin(badness)
#.....
end
end
</pre>

By implementing sin methods in different modules eliminates name clashes since the methods will now be referenced in a class which includes these modules. The modules can be included in a class using the require statement, this is shown as follows:

<pre>
require Math
require Action

sinValue = Math.sin(Math::PI/2)
bad_action = Action.sin(Action::BAD)
</pre>

[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Module methods][6] are invoked in the same manner as class methods by preceding its name with the module's name and a period, and by referencing a constant using the module name and two colons.

<h2>[http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby Types of mixins][7]</h2>
The following example demonstrates two types of mixins. Consider the following example of a module,
<pre>
module Example

def example
if @variable > 0
return 1
else
return 0
end

end
</pre>
The Example module makes use of @variable instance variable. The class which mixes this module has to define the @variable since the Example module makes use of @variable but does not define it. A module can make use of methods not defined within the module but the class in which it has been mixed in. Thus, this module exhibits dependency on the implementation of the class it is mixed with.

The following example demonstrates an independent module ,
<pre>
module AddSub

#Class method
def add(var_one, var_two)
SampleClass.new(var_one + var_two)
end

end
</pre>

The Addition module defines a class method as well as an instance method. Class methods are also known as static methods. The add method in the AddSub module defines accepts two integers and returns an instance of SampleClass. The mixin SampleClass class is defined as follows:

<pre>
# Base Integer class
Class Integer
def value
@variable
end
end

# SampleClass extends Integer
class SampleClass < Integer

# Add instance methods from Example
include Stringify

# Add class methods from AddSub
extend AddSub

# Add a constructor with one parameter
def initialize(value)
@variable = value
end
end
</pre>

The module methods have been mixed into the class using the include and extend methods respectively. The extend method will mix the methods as class/static methods.
<pre>
#Call class method from AddSub module

object1 = SampleClass.add(2,3)
puts object1.value # -> 5
</pre>

The include method will mix the methods defined in the module as instance methods.
<pre>
#Call instance method from Example module

puts object1.example # -> 1
</pre>
However, care must be taken that including an instance method does not copy the module's instance methods into the class. A reference is generated from the class to the included module. This applies to all the classes which have included the module. If any change is made in the
instance method it will be reflected in the behavior of all the classes that include the
module.
The extend method comes with an additional feature. An object instance can be enhanced at run time by mixing it in a module at run time.

<pre>
module ScaleValue
def multiply
“#{@variable}*100”
end
end
</pre>

An object instance can be extended with a module using the following commands:
<pre>
#Adding module methods to this object instance only!

object1.extend ScaleValue
puts object1.multiply # -> 500
</pre>

The extend method includes the module methods only on object1, the remaining objects will not this functionality.

<pre>
puts object2.multiple # generate error
</pre>

<h2>Mix-in is a contract</h2>
The Enumerable module provides various methods as a mixin to a given class. However, the module assumes that all the objects of a given class respond to <i>each</i> method. Apart from this, Enumerable provides methods which can be used to query an object whether it responds to a given method or not. Given the ability of an object to respond to <i>each</i> method which iterates over the collection of elements one can make use of following methods to find out the properties of an object. Some of the methods Enumerable provides are as follows:

• all?, any?, collect, find, include?, inject, map, and partition

In Java one can find the declaration “Array implements Enumerable”, no such declaration is found in Ruby. The reason being the methods in Enumerable module assume that the target objects are capable of responding to the methods invoked on them.

Comparable is another module which assumes that objects of a given class respond to < = > (spaceship) operator. Similar to the Enumerable module, Comparable provides various methods for comparing the objects and some of them are mentioned below:

• <, <=, >, >=, ==, and between?

Given a class which implements spaceship operator and <i>each</i> method, the objects can make use of sort method which requires implementation of spaceship operator so that the objects are capable to comparing with each other and the <i>each</i> method in order to retrieve the objects one at a time. By mixing modules within a class, an object can perform various actions such as map, reduce, and many more. The classes do not matter unless they respond to certain methods. Consider an example of constructing a data structure, by implementing <i>each</i> method the data structure can implement various methods such as sort, map, reduce etc in its own way. Thus, mixing modules facilitate behavior reuse which is an added advantage.

The video lecture presents an example of Account class which implements spaceship operator.
The spaceship operator is used to compare the balance of two different objects.

<pre>
class Account
include Comparable
def <=>(other)
self.balance <=> other.balance
end
end

</pre>

On defining the spaceship operator the objects of Account class can define of all the other methods Comparable module provides. In this manner the Account class takes advantage of behavior reuse.

<h1>References</h1>
*[1] http://www.youtube.com/watch?v=Q1h-W0sWVoM
*[2] http://en.wikipedia.org/wiki/Duck_typing
*[3] http://www.codecapers.com/post/Duck-Typing.aspx
*[4] http://en.wikipedia.org/wiki/Programming_language#Type_system
*[5] http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/
*[6] http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html
*[7] http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/

<h1>Additional Reading</h1>
* Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
* [http://beust.com/weblog/2005/04/15/the-perils-of-duck-typing/ Perils of Duck Typing]
* [http://stackoverflow.com/questions/4205130/what-is-duck-typing What is Duck Typing : Stack Overflow]
* [http://en.wikipedia.org/wiki/Type_system What actually do you mean by 'Type']

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T20:58:32Z

Nmsarda:

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T20:51:36Z

Nmsarda:

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T20:47:49Z

Nmsarda:

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T20:44:54Z

Nmsarda:

<h1>SaaS - 3.7. Mixins and Duck Typing</h1>
This wiki is aimed at acting as a complementary read to the SaaS - 3.7. Mixins and Duck Typing lecture. This lecture describes three of the most important fundamentals of the Ruby language: Duck-Typing, Modules and Mixins.
<h1>Introduction</h1>
*Duck-typing is one of the main features of many object-oriented languages. Duck-Typing describes how a language like Ruby, treats its objects as compared to a language like JAVA. We describe the beautiful features of Duck-typing and also its negative side-effects.<br>
*Modules define a namespace. It provides a mechanism to club several things together which naturally do-not form a common class. With modules, programmer does not have to worry of possible name-clashes of method name's with other methods written by different programmers. Modules handles this by making use of namespace.<br>
*Mixins extend from modules. modules are not classes and hence we cannot instantiate them. However, when modules are 'include'ed in a class, all its methods are available to that class. We say modules are 'mixed in' to the class or in other words 'mixins'. Modules which are mixed in behave as superclass and provide multiple inheritance.

<h1>[http://en.wikipedia.org/wiki/Duck_typing Duck Typing][1]</h1>
<h2>What is Duck Typing</h2>
'''“If a object walks like a duck, quacks like a duck then treat it as a duck”'''

[[File:Dtype.png|frame|left|[http://www.codecapers.com/post/Duck-Typing.aspx A cat or a duck or a cat walking like a duck?][2]]]
<br><br><br><br><br>This is the ‘mantra’ of Ruby language and the most pleasing aspect of the language. What it means is that, whether an object responds to a method?, is only important and not the type of the object.
If a dragon responds to methods like swim and quacking, ruby is happy to treat dragon as a duck without having a concern of whether it actually is a duck or not. This gives powerful tools for a ruby programmer.

This is possible in Ruby because we don’t declare the '[http://en.wikipedia.org/wiki/Programming_language#Type_system Type][3] of variables or methods like in JAVA; in Ruby, everything is an object and each object can be individually modified, irrespective of its implementation in the class to which it belongs.
<br>

<br><br><br><br>
Consider the following example taken from the SAAS lecture:
<pre>
my_list.sort

[5, 4, 3].sort
["dog", "cat", "rat"].sort
[:a, :b, :c].sort
</pre>

Here, the same function, sort, is responding to an array of integers, strings and literals. This is classic Ruby duck-typing at work. How sort works is that it compares the elements which are needed to be sorted. So as long as the elements can be compared, sort function works. In the above example, the array of integers, strings and literals implement the comparison operator and hence the same sort function works for all of them.

<h2> Why in Ruby and not in JAVA? </h2>
The reason for duck-typing to be easily possible and implemented in language like Ruby and not in language like JAVA is that these 2 languages treat ‘type’ differently.
In JAVA or C++, type means class. When someone asks the type of “abc”, we say it is String. So, such language allows String objects to refer to only other String objects.
String a; a will never be allowed to refer to anything other than a string, like a=5.

While in Ruby, type refers to how the object reacts to a method or in other words does the object have a particular capability. Type refers to this capability. While a class to which the object belongs provides the initial capabilities, from that point on, the object is free to extend its capabilities independently of its pre-defined class. So,

a= ”abc”
a= 5 are two perfectly acceptable statements in Ruby.

This is duck-typing.
[http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/ A classic example][3] of how a scripting language, JavaScript, not implementing duck-typing can lead to some bad code.

<h2> Duck-Typing in action</h2>
<pre>
class American
def football
puts "We play it with hands"
end

end

class European
def football
puts "We play it with legs"
end
end

class Martian
end

footballManiac = [American.new,European.new]

footballManiac.each {|game| game.football}
</pre>

Output of this program is We play it with hands(next line) We play it with legs

This is because of duck-typing. footballManiac first acted as an American class object and since that class responded to the football method, it executed it. Then it acted as an European class object and again that class responded to the method, it executed it. In static-typed languages, we would have to type cast each object and even then we might get compile time or run time error. Nothing of that sorts in Ruby. Now let us also create a Martian class object.

<pre>
footballManiac = [American.new,European.new,Martian.new]

footballManiac.each {|game| game.football}
</pre>

On executing it, we get the following error
<pre>undefined method `football' for #<Martian:0x3425358> (NoMethodError)</pre>
This is obvious because martians do not play football. But the point is, Ruby still checked the martian class and when it found that the object does not respond to the method, it complained.

<h2> The other side to Duck-Typing </h2>
As with everything in life, there is always 2 perspectives about its usefulness. Following are some of the criticism against duck-typing :
<h3>Lack of compiler security</h3>
There is no help from compiler for a programmer error like assigning a string to an integer and so on. Only when you run the code, the output might be funny and that’s when you realize a probable mistake in assignment. In a static-type language, there is always a compiler check and hence the problem does not arise. Obviously this problem can be alleviated by proper and exhaustive testing. But as we all know, no one can guarantee 100% code tests.
<h3>Contract between caller and the callee</h3>
In a static type language, the caller knows the exact ‘type’ of parameters required by the callee and also the return-type from the callee. In dynamic type languages, no type is provided. So to understand what the callee expects, one has to look at the code and understand. This is difficult in most of the cases and mainly for third-party code. Again this problem can be solved by providing proper documentation of each API and the pre-requirements for execution. But who can guarantee that the documents correctly map the requirements?

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T20:43:35Z

Nmsarda:

<h1>SaaS - 3.7. Mixins and Duck Typing</h1>
This wiki is aimed at acting as a complementary read to the SaaS - 3.7. Mixins and Duck Typing lecture. This lecture describes three of the most important fundamentals of the Ruby language: Duck-Typing, Modules and Mixins.
<h1>Introduction</h1>
*Duck-typing is one of the main features of many object-oriented languages. Duck-Typing describes how a language like Ruby, treats its objects as compared to a language like JAVA. We describe the beautiful features of Duck-typing and also its negative side-effects.<br>
*Modules define a namespace. It provides a mechanism to club several things together which naturally do-not form a common class. With modules, programmer does not have to worry of possible name-clashes of method name's with other methods written by different programmers. Modules handles this by making use of namespace.<br>
*Mixins extend from modules. modules are not classes and hence we cannot instantiate them. However, when modules are 'include'ed in a class, all its methods are available to that class. We say modules are 'mixed in' to the class or in other words 'mixins'. Modules which are mixed in behave as superclass and provide multiple inheritance.

<h1>[http://en.wikipedia.org/wiki/Duck_typing Duck Typing][1]</h1>
<h2>What is Duck Typing</h2>
'''“If a object walks like a duck, quacks like a duck then treat it as a duck”'''

[[File:Dtype.png|frame|left|[http://www.codecapers.com/post/Duck-Typing.aspx A cat or a duck?][2]]]
<br><br><br><br><br>This is the ‘mantra’ of Ruby language and the most pleasing aspect of the language. What it means is that, whether an object responds to a method?, is only important and not the type of the object.
If a dragon responds to methods like swim and quacking, ruby is happy to treat dragon as a duck without having a concern of whether it actually is a duck or not. This gives powerful tools for a ruby programmer.

This is possible in Ruby because we don’t declare the '[http://en.wikipedia.org/wiki/Programming_language#Type_system Type][3] of variables or methods like in JAVA; in Ruby, everything is an object and each object can be individually modified, irrespective of its implementation in the class to which it belongs.
<br>

<br><br><br><br>
Consider the following example taken from the SAAS lecture:
<pre>
my_list.sort

[5, 4, 3].sort
["dog", "cat", "rat"].sort
[:a, :b, :c].sort
</pre>

Here, the same function, sort, is responding to an array of integers, strings and literals. This is classic Ruby duck-typing at work. How sort works is that it compares the elements which are needed to be sorted. So as long as the elements can be compared, sort function works. In the above example, the array of integers, strings and literals implement the comparison operator and hence the same sort function works for all of them.

<h2> Why in Ruby and not in JAVA? </h2>
The reason for duck-typing to be easily possible and implemented in language like Ruby and not in language like JAVA is that these 2 languages treat ‘type’ differently.
In JAVA or C++, type means class. When someone asks the type of “abc”, we say it is String. So, such language allows String objects to refer to only other String objects.
String a; a will never be allowed to refer to anything other than a string, like a=5.

While in Ruby, type refers to how the object reacts to a method or in other words does the object have a particular capability. Type refers to this capability. While a class to which the object belongs provides the initial capabilities, from that point on, the object is free to extend its capabilities independently of its pre-defined class. So,

a= ”abc”
a= 5 are two perfectly acceptable statements in Ruby.

This is duck-typing.
[http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/ A classic example][3] of how a scripting language, JavaScript, not implementing duck-typing can lead to some bad code.

<h2> Duck-Typing in action</h2>
<pre>
class American
def football
puts "We play it with hands"
end

end

class European
def football
puts "We play it with legs"
end
end

class Martian
end

footballManiac = [American.new,European.new]

footballManiac.each {|game| game.football}
</pre>

Output of this program is We play it with hands(next line) We play it with legs

This is because of duck-typing. footballManiac first acted as an American class object and since that class responded to the football method, it executed it. Then it acted as an European class object and again that class responded to the method, it executed it. In static-typed languages, we would have to type cast each object and even then we might get compile time or run time error. Nothing of that sorts in Ruby. Now let us also create a Martian class object.

<pre>
footballManiac = [American.new,European.new,Martian.new]

footballManiac.each {|game| game.football}
</pre>

On executing it, we get the following error
<pre>undefined method `football' for #<Martian:0x3425358> (NoMethodError)</pre>
This is obvious because martians do not play football. But the point is, Ruby still checked the martian class and when it found that the object does not respond to the method, it complained.

<h2> The other side to Duck-Typing </h2>
As with everything in life, there is always 2 perspectives about its usefulness. Following are some of the criticism against duck-typing :
<h3>Lack of compiler security</h3>
There is no help from compiler for a programmer error like assigning a string to an integer and so on. Only when you run the code, the output might be funny and that’s when you realize a probable mistake in assignment. In a static-type language, there is always a compiler check and hence the problem does not arise. Obviously this problem can be alleviated by proper and exhaustive testing. But as we all know, no one can guarantee 100% code tests.
<h3>Contract between caller and the callee</h3>
In a static type language, the caller knows the exact ‘type’ of parameters required by the callee and also the return-type from the callee. In dynamic type languages, no type is provided. So to understand what the callee expects, one has to look at the code and understand. This is difficult in most of the cases and mainly for third-party code. Again this problem can be solved by providing proper documentation of each API and the pre-requirements for execution. But who can guarantee that the documents correctly map the requirements?

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T20:34:55Z

Nmsarda:

<h1>SaaS - 3.7. Mixins and Duck Typing</h1>
This wiki is aimed at acting as a complementary read to the SaaS - 3.7. Mixins and Duck Typing lecture. This lecture describes three of the most important fundamentals of the Ruby language: Duck-Typing, Modules and Mixins.
<h1>Introduction</h1>
*Duck-typing is one of the main features of many object-oriented languages. Duck-Typing describes how a language like Ruby, treats its objects as compared to a language like JAVA. We describe the beautiful features of Duck-typing and also its negative side-effects.<br>
*Modules define a namespace. It provides a mechanism to club several things together which naturally do-not form a common class. With modules, programmer does not have to worry of possible name-clashes of method name's with other methods written by different programmers. Modules handles this by making use of namespace.<br>
*Mixins extend from modules. modules are not classes and hence we cannot instantiate them. However, when modules are 'include'ed in a class, all its methods are available to that class. We say modules are 'mixed in' to the class or in other words 'mixins'. Modules which are mixed in behave as superclass and provide multiple inheritance.

<h1>[http://en.wikipedia.org/wiki/Duck_typing Duck Typing][1]</h1>
<h2>What is Duck Typing</h2>
'''“If a object walks like a duck, quacks like a duck then treat it as a duck”'''
[http://www.codecapers.com/post/Duck-Typing.aspx[[File:Dtype.png]]][2]
<br><br>This is the ‘mantra’ of Ruby language and the most pleasing aspect of the language. What it means is that, whether an object responds to a method?, is only important and not the type of the object.
If a dragon responds to methods like swim and quacking, ruby is happy to treat dragon as a duck without having a concern of whether it actually is a duck or not. This gives powerful tools for a ruby programmer.

This is possible in Ruby because we don’t declare the '[http://en.wikipedia.org/wiki/Programming_language#Type_system Type][3] of variables or methods like in JAVA; in Ruby, everything is an object and each object can be individually modified, irrespective of its implementation in the class to which it belongs.

Consider the following example taken from the SAAS lecture:
<pre>
my_list.sort

[5, 4, 3].sort
["dog", "cat", "rat"].sort
[:a, :b, :c].sort
</pre>

Here, the same function, sort, is responding to an array of integers, strings and literals. This is classic Ruby duck-typing at work. How sort works is that it compares the elements which are needed to be sorted. So as long as the elements can be compared, sort function works. In the above example, the array of integers, strings and literals implement the comparison operator and hence the same sort function works for all of them.

<h2> Why in Ruby and not in JAVA? </h2>
The reason for duck-typing to be easily possible and implemented in language like Ruby and not in language like JAVA is that these 2 languages treat ‘type’ differently.
In JAVA or C++, type means class. When someone asks the type of “abc”, we say it is String. So, such language allows String objects to refer to only other String objects.
String a; a will never be allowed to refer to anything other than a string, like a=5.

While in Ruby, type refers to how the object reacts to a method or in other words does the object have a particular capability. Type refers to this capability. While a class to which the object belongs provides the initial capabilities, from that point on, the object is free to extend its capabilities independently of its pre-defined class. So,

a= ”abc”
a= 5 are two perfectly acceptable statements in Ruby.

This is duck-typing.
[http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/ A classic example][3] of how a scripting language, JavaScript, not implementing duck-typing can lead to some bad code.

<h2> Duck-Typing in action</h2>
<pre>
class American
def football
puts "We play it with hands"
end

end

class European
def football
puts "We play it with legs"
end
end

class Martian
end

footballManiac = [American.new,European.new]

footballManiac.each {|game| game.football}
</pre>

Output of this program is We play it with hands(next line) We play it with legs

This is because of duck-typing. footballManiac first acted as an American class object and since that class responded to the football method, it executed it. Then it acted as an European class object and again that class responded to the method, it executed it. In static-typed languages, we would have to type cast each object and even then we might get compile time or run time error. Nothing of that sorts in Ruby. Now let us also create a Martian class object.

<pre>
footballManiac = [American.new,European.new,Martian.new]

footballManiac.each {|game| game.football}
</pre>

On executing it, we get the following error
<pre>undefined method `football' for #<Martian:0x3425358> (NoMethodError)</pre>
This is obvious because martians do not play football. But the point is, Ruby still checked the martian class and when it found that the object does not respond to the method, it complained.

<h2> The other side to Duck-Typing </h2>
As with everything in life, there is always 2 perspectives about its usefulness. Following are some of the criticism against duck-typing :
<h3>Lack of compiler security</h3>
There is no help from compiler for a programmer error like assigning a string to an integer and so on. Only when you run the code, the output might be funny and that’s when you realize a probable mistake in assignment. In a static-type language, there is always a compiler check and hence the problem does not arise. Obviously this problem can be alleviated by proper and exhaustive testing. But as we all know, no one can guarantee 100% code tests.
<h3>Contract between caller and the callee</h3>
In a static type language, the caller knows the exact ‘type’ of parameters required by the callee and also the return-type from the callee. In dynamic type languages, no type is provided. So to understand what the callee expects, one has to look at the code and understand. This is difficult in most of the cases and mainly for third-party code. Again this problem can be solved by providing proper documentation of each API and the pre-requirements for execution. But who can guarantee that the documents correctly map the requirements?

File:Dtype.png

2012-11-18T20:32:03Z

Nmsarda: Duck type in ruby

Duck type in ruby

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T20:25:17Z

Nmsarda:

<h1>SaaS - 3.7. Mixins and Duck Typing</h1>
This wiki is aimed at acting as a complementary read to the SaaS - 3.7. Mixins and Duck Typing lecture. This lecture describes three of the most important fundamentals of the Ruby language: Duck-Typing, Modules and Mixins.
<h1>Introduction</h1>
*Duck-typing is one of the main features of many object-oriented languages. Duck-Typing describes how a language like Ruby, treats its objects as compared to a language like JAVA. We describe the beautiful features of Duck-typing and also its negative side-effects.<br>
*Modules define a namespace. It provides a mechanism to club several things together which naturally do-not form a common class. With modules, programmer does not have to worry of possible name-clashes of method name's with other methods written by different programmers. Modules handles this by making use of namespace.<br>
*Mixins extend from modules. modules are not classes and hence we cannot instantiate them. However, when modules are 'include'ed in a class, all its methods are available to that class. We say modules are 'mixed in' to the class or in other words 'mixins'. Modules which are mixed in behave as superclass and provide multiple inheritance.

<h1>[http://en.wikipedia.org/wiki/Duck_typing Duck Typing][1]</h1>
<h2>What is Duck Typing</h2>[http://threebrothers.org/brendan/blog/death-by-duck-typing/[[File:Duckt.gif]]][2]
'''“If a object walks like a duck, quacks like a duck then treat it as a duck”'''
This is the ‘mantra’ of Ruby language and the most pleasing aspect of the language. What it means is that, whether an object responds to a method?, is only important and not the type of the object.
If a dragon responds to methods like swim and quacking, ruby is happy to treat dragon as a duck without having a concern of whether it actually is a duck or not. This gives powerful tools for a ruby programmer.

This is possible in Ruby because we don’t declare the '[http://en.wikipedia.org/wiki/Programming_language#Type_system Type][3] of variables or methods like in JAVA; in Ruby, everything is an object and each object can be individually modified, irrespective of its implementation in the class to which it belongs.

Consider the following example taken from the SAAS lecture:
<pre>
my_list.sort

[5, 4, 3].sort
["dog", "cat", "rat"].sort
[:a, :b, :c].sort
</pre>

Here, the same function, sort, is responding to an array of integers, strings and literals. This is classic Ruby duck-typing at work. How sort works is that it compares the elements which are needed to be sorted. So as long as the elements can be compared, sort function works. In the above example, the array of integers, strings and literals implement the comparison operator and hence the same sort function works for all of them.

<h2> Why in Ruby and not in JAVA? </h2>
The reason for duck-typing to be easily possible and implemented in language like Ruby and not in language like JAVA is that these 2 languages treat ‘type’ differently.
In JAVA or C++, type means class. When someone asks the type of “abc”, we say it is String. So, such language allows String objects to refer to only other String objects.
String a; a will never be allowed to refer to anything other than a string, like a=5.

While in Ruby, type refers to how the object reacts to a method or in other words does the object have a particular capability. Type refers to this capability. While a class to which the object belongs provides the initial capabilities, from that point on, the object is free to extend its capabilities independently of its pre-defined class. So,

a= ”abc”
a= 5 are two perfectly acceptable statements in Ruby.

This is duck-typing.
[http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/ A classic example][3] of how a scripting language, JavaScript, not implementing duck-typing can lead to some bad code.

<h2> Duck-Typing in action</h2>
<pre>
class American
def football
puts "We play it with hands"
end

end

class European
def football
puts "We play it with legs"
end
end

class Martian
end

footballManiac = [American.new,European.new]

footballManiac.each {|game| game.football}
</pre>

Output of this program is We play it with hands(next line) We play it with legs

This is because of duck-typing. footballManiac first acted as an American class object and since that class responded to the football method, it executed it. Then it acted as an European class object and again that class responded to the method, it executed it. In static-typed languages, we would have to type cast each object and even then we might get compile time or run time error. Nothing of that sorts in Ruby. Now let us also create a Martian class object.

<pre>
footballManiac = [American.new,European.new,Martian.new]

footballManiac.each {|game| game.football}
</pre>

On executing it, we get the following error
<pre>undefined method `football' for #<Martian:0x3425358> (NoMethodError)</pre>
This is obvious because martians do not play football. But the point is, Ruby still checked the martian class and when it found that the object does not respond to the method, it complained.

<h2> The other side to Duck-Typing </h2>
As with everything in life, there is always 2 perspectives about its usefulness. Following are some of the criticism against duck-typing :
<h3>Lack of compiler security</h3>
There is no help from compiler for a programmer error like assigning a string to an integer and so on. Only when you run the code, the output might be funny and that’s when you realize a probable mistake in assignment. In a static-type language, there is always a compiler check and hence the problem does not arise. Obviously this problem can be alleviated by proper and exhaustive testing. But as we all know, no one can guarantee 100% code tests.
<h3>Contract between caller and the callee</h3>
In a static type language, the caller knows the exact ‘type’ of parameters required by the callee and also the return-type from the callee. In dynamic type languages, no type is provided. So to understand what the callee expects, one has to look at the code and understand. This is difficult in most of the cases and mainly for third-party code. Again this problem can be solved by providing proper documentation of each API and the pre-requirements for execution. But who can guarantee that the documents correctly map the requirements?

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T18:26:30Z

Nmsarda:

<h1>SaaS - 3.7. Mixins and Duck Typing</h1>
This wiki is aimed at acting as a complementary read to the SaaS - 3.7. Mixins and Duck Typing lecture. This lecture describes three of the most important fundamentals of the Ruby language: Duck-Typing, Modules and Mixins.
<h1>Introduction</h1>
*Duck-typing is one of the main features of many object-oriented languages. Duck-Typing describes how a language like Ruby, treats its objects as compared to a language like JAVA. We describe the beautiful features of Duck-typing and also its negative side-effects.<br>
*Modules define a namespace. It provides a mechanism to club several things together which naturally do-not form a common class. With modules, programmer does not have to worry of possible name-clashes of method name's with other methods written by different programmers. Modules handles this by making use of namespace.<br>
*Mixins extend from modules. modules are not classes and hence we cannot instantiate them. However, when modules are 'include'ed in a class, all its methods are available to that class. We say modules are 'mixed in' to the class or in other words 'mixins'. Modules which are mixed in behave as superclass and provide multiple inheritance.

<h1>[http://en.wikipedia.org/wiki/Duck_typing Duck Typing][1]</h1>
<h2>What is Duck Typing</h2>[http://threebrothers.org/brendan/blog/death-by-duck-typing/[[File:Duckt.gif]]][2]
'''“If a object walks like a duck, quacks like a duck then treat it as a duck”'''
This is the ‘mantra’ of Ruby language and the most pleasing aspect of the language. What it means is that, whether an object responds to a method?, is only important and not the type of the object.
If a dragon responds to methods like swim and quacking, ruby is happy to treat dragon as a duck without having a concern of whether it actually is a duck or not. This gives powerful tools for a ruby programmer.

This is possible in Ruby because we don’t declare the '[http://en.wikipedia.org/wiki/Programming_language#Type_system Type][3] of variables or methods like in JAVA; in Ruby, everything is an object and each object can be individually modified, irrespective of its implementation in the class to which it belongs.

Consider the following example taken from the SAAS lecture:
<pre>
my_list.sort

[5, 4, 3].sort
["dog", "cat", "rat"].sort
[:a, :b, :c].sort
</pre>

Here, the same function, sort, is responding to an array of integers, strings and literals. This is classic Ruby duck-typing at work. How sort works is that it compares the elements which are needed to be sorted. So as long as the elements can be compared, sort function works. In the above example, the array of integers, strings and literals implement the comparison operator and hence the same sort function works for all of them.

<h2> Why in Ruby and not in JAVA? </h2>
The reason for duck-typing to be easily possible and implemented in language like Ruby and not in language like JAVA is that these 2 languages treat ‘type’ differently.
In JAVA or C++, type means class. When someone asks the type of “abc”, we say it is String. So, such language allows String objects to refer to only other String objects.
String a; a will never be allowed to refer to anything other than a string, like a=5.

While in Ruby, type refers to how the object reacts to a method or in other words does the object have a particular capability. Type refers to this capability. While a class to which the object belongs provides the initial capabilities, from that point on, the object is free to extend its capabilities independently of its pre-defined class. So,

a= ”abc”
a= 5 are two perfectly acceptable statements in Ruby.

This is duck-typing.
[http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/ A classic example][3] of how a scripting language, JavaScript, not implementing duck-typing can lead to some bad code.

<h2> Duck-Typing in action</h2>
<pre>
class American
def football
puts "We play it with hands"
end

end

class European
def football
puts "We play it with legs"
end
end

class Martian
end

footballManiac = [American.new,European.new]

footballManiac.each {|game| game.football}
</pre>

Output of this program is We play it with hands(next line) We play it with legs

This is because of duck-typing. footballManiac first acted as an American class object and since that class responded to the football method, it executed it. Then it acted as an European class object and again that class responded to the method, it executed it. In static-typed languages, we would have to type cast each object and even then we might get compile time or run time eeror. Nothing of that sorts in Ruby. Now let us also create a Martian class object.

<pre>
footballManiac = [American.new,European.new,Martian.new]

footballManiac.each {|game| game.football}
</pre>

On executing it, we get the following error
<pre>undefined method `football' for #<Martian:0x3425358> (NoMethodError)</pre>
This is obvious because martians do not play football. But the point is, Ruby still checked the martian class and when it found that the object does not respond to the method, it complained.

<h2> The other side to Duck-Typing </h2>
As with everything in life, there is always 2 perspectives about its usefulness. Following are some of the criticism against duck-typing :
<h3>Lack of compiler security</h3>
There is no help from compiler for a programmer error like assigning a string to an integer and so on. Only when you run the code, the output might be funny and that’s when you realize a probable mistake in assignment. In a static-type language, there is always a compiler check and hence the problem does not arise. Obviously this problem can be alleviated by proper and exhaustive testing. But as we all know, no one can guarantee 100% code tests.
<h3>Contract between caller and the callee</h3>
In a static type language, the caller knows the exact ‘type’ of parameters required by the callee and also the return-type from the callee. In dynamic type languages, no type is provided. So to understand what the callee expects, one has to look at the code and understand. This is difficult in most of the cases and mainly for third-party code. Again this problem can be solved by providing proper documentation of each API and the pre-requirements for execution. But who can guarantee that the documents correctly map the requirements?

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T17:59:28Z

Nmsarda:

<h1>SaaS - 3.7. Mixins and Duck Typing</h1>
This wiki is aimed at acting as a complementary read to the SaaS - 3.7. Mixins and Duck Typing lecture. This lecture describes three of the most important fundamentals of the Ruby language: Duck-Typing, Modules and Mixins.
<h1>Introduction</h1>
*Duck-typing is one of the main features of many object-oriented languages. Duck-Typing describes how a language like Ruby, treats its objects as compared to a language like JAVA. We describe the beautiful features of Duck-typing and also its negative side-effects.<br>
*Modules define a namespace. It provides a mechanism to club several things together which naturally do-not form a common class. With modules, programmer does not have to worry of possible name-clashes of method name's with other methods written by different programmers. Modules handles this by making use of namespace.<br>
*Mixins extend from modules. modules are not classes and hence we cannot instantiate them. However, when modules are 'include'ed in a class, all its methods are available to that class. We say modules are 'mixed in' to the class or in other words 'mixins'. Modules which are mixed in behave as superclass and provide multiple inheritance.

<h1>[http://en.wikipedia.org/wiki/Duck_typing Duck Typing][1]</h1>
<h2>What is Duck Typing</h2>[http://threebrothers.org/brendan/blog/death-by-duck-typing/[[File:Duckt.gif]]][2]
'''“If a object walks like a duck, quacks like a duck then treat it as a duck”'''
This is the ‘mantra’ of Ruby language and the most pleasing aspect of the language. What it means is that, whether an object responds to a method?, is only important and not the type of the object.
If a dragon responds to methods like swim and quacking, ruby is happy to treat dragon as a duck without having a concern of whether it actually is a duck or not. This gives powerful tools for a ruby programmer.

This is possible in Ruby because we don’t declare the '[http://en.wikipedia.org/wiki/Programming_language#Type_system Type][3] of variables or methods like in JAVA; in Ruby, everything is an object and each object can be individually modified, irrespective of its implementation in the class to which it belongs.

Consider the following example taken from the SAAS lecture:
<pre>
my_list.sort

[5, 4, 3].sort
["dog", "cat", "rat"].sort
[:a, :b, :c].sort
</pre>

Here, the same function, sort, is responding to an array of integers, strings and literals. This is classic Ruby duck-typing at work. How sort works is that it compares the elements which are needed to be sorted. So as long as the elements can be compared, sort function works. In the above example, the array of integers, strings and literals implement the comparison operator and hence the same sort function works for all of them.

<h2> Why in Ruby and not in JAVA? </h2>
The reason for duck-typing to be easily possible and implemented in language like Ruby and not in language like JAVA is that these 2 languages treat ‘type’ differently.
In JAVA or C++, type means class. When someone asks the type of “abc”, we say it is String. So, such language allows String objects to refer to only other String objects.
String a; a will never be allowed to refer to anything other than a string, like a=5.

While in Ruby, type refers to how the object reacts to a method or in other words does the object have a particular capability. Type refers to this capability. While a class to which the object belongs provides the initial capabilities, from that point on, the object is free to extend its capabilities independently of its pre-defined class. So,

a= ”abc”
a= 5 are two perfectly acceptable statements in Ruby.

This is duck-typing.

<h2> Duck-Typing in action</h2>
<pre>
class American
def football
puts "We play it with hands"
end

end

class European
def football
puts "We play it with legs"
end
end

class Martian

end

footballManiac = [American.new,European.new]

footballManiac.each {|game| game.football}
</pre>

[http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/ A classic example][3] of how a scripting language, JavaScript, not implementing duck-typing can lead to some bad code.

<h2> The other side to Duck-Typing </h2>
As with everything in life, there is always 2 perspectives about its usefulness. Following are some of the criticism against duck-typing :
<h3>Lack of compiler security</h3>
There is no help from compiler for a programmer error like assigning a string to an integer and so on. Only when you run the code, the output might be funny and that’s when you realize a probable mistake in assignment. In a static-type language, there is always a compiler check and hence the problem does not arise. Obviously this problem can be alleviated by proper and exhaustive testing. But as we all know, no one can guarantee 100% code tests.
<h3>Contract between caller and the callee</h3>
In a static type language, the caller knows the exact ‘type’ of parameters required by the callee and also the return-type from the callee. In dynamic type languages, no type is provided. So to understand what the callee expects, one has to look at the code and understand. This is difficult in most of the cases and mainly for third-party code. Again this problem can be solved by providing proper documentation of each API and the pre-requirements for execution. But who can guarantee that the documents correctly map the requirements?

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T17:25:27Z

Nmsarda:

<h1>SaaS - 3.7. Mixins and Duck Typing</h1>
This wiki is aimed at acting as a complementary read to the SaaS - 3.7. Mixins and Duck Typing lecture. This lecture describes three of the most important fundamentals of the Ruby language: Duck-Typing, Modules and Mixins.
<h1>Introduction</h1>
*Duck-typing is one of the main features of many object-oriented languages. Duck-Typing describes how a language like Ruby, treats its objects as compared to a language like JAVA. We describe the beautiful features of Duck-typing and also its negative side-effects.<br>
*Modules define a namespace. It provides a mechanism to club several things together which naturally do-not form a common class. With modules, programmer does not have to worry of possible name-clashes of method name's with other methods written by different programmers. Modules handles this by making use of namespace.<br>
*Mixins extend from modules. modules are not classes and hence we cannot instantiate them. However, when modules are 'include'ed in a class, all its methods are available to that class. We say modules are 'mixed in' to the class or in other words 'mixins'. Modules which are mixed in behave as superclass and provide multiple inheritance.

<h1>[http://en.wikipedia.org/wiki/Duck_typing Duck Typing][1]</h1>
<h2>What is Duck Typing</h2>[http://threebrothers.org/brendan/blog/death-by-duck-typing/[[File:Duckt.gif]]][2]
'''“If a object walks like a duck, quacks like a duck then treat it as a duck”'''
This is the ‘mantra’ of Ruby language and the most pleasing aspect of the language. What it means is that, whether an object responds to a method?, is only important and not the type of the object.
If a dragon responds to methods like swim and quacking, ruby is happy to treat dragon as a duck without having a concern of whether it actually is a duck or not. This gives powerful tools for a ruby programmer.

This is possible in Ruby because we don’t declare the '[http://en.wikipedia.org/wiki/Programming_language#Type_system Type][3] of variables or methods like in JAVA; in Ruby, everything is an object and each object can be individually modified, irrespective of its implementation in the class to which it belongs.

Consider the following example taken from the SAAS lecture:
<pre>
my_list.sort

[5, 4, 3].sort
["dog", "cat", "rat"].sort
[:a, :b, :c].sort
</pre>

Here, the same function, sort, is responding to an array of integers, strings and literals. This is classic Ruby duck-typing at work. How sort works is that it compares the elements which are needed to be sorted. So as long as the elements can be compared, sort function works. In the above example, the array of integers, strings and literals implement the comparison operator and hence the same sort function works for all of them.

<h2> Why in Ruby and not in JAVA? </h2>
The reason for duck-typing to be easily possible and implemented in language like Ruby and not in language like JAVA is that these 2 languages treat ‘type’ differently.
In JAVA or C++, type means class. When someone asks the type of “abc”, we say it is String. So, such language allows String objects to refer to only other String objects.
String a; a will never be allowed to refer to anything other than a string, like a=5.

While in Ruby, type refers to how the object reacts to a method or in other words does the object have a particular capability. Type refers to this capability. While a class to which the object belongs provides the initial capabilities, from that point on, the object is free to extend its capabilities independently of its pre-defined class. So,

a= ”abc”
a= 5 are two perfectly acceptable statements in Ruby.

This is duck-typing.

[http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/ A classic example][3] of how a scripting language, JavaScript, not implementing duck-typing can lead to some bad code.

<h2> The other side to Duck-Typing </h2>
As with everything in life, there is always 2 perspectives about its usefulness. Following are some of the criticism against duck-typing :
<h3>Lack of compiler security</h3>
There is no help from compiler for a programmer error like assigning a string to an integer and so on. Only when you run the code, the output might be funny and that’s when you realize a probable mistake in assignment. In a static-type language, there is always a compiler check and hence the problem does not arise. Obviously this problem can be alleviated by proper and exhaustive testing. But as we all know, no one can guarantee 100% code tests.
<h3>Contract between caller and the callee</h3>
In a static type language, the caller knows the exact ‘type’ of parameters required by the callee and also the return-type from the callee. In dynamic type languages, no type is provided. So to understand what the callee expects, one has to look at the code and understand. This is difficult in most of the cases and mainly for third-party code. Again this problem can be solved by providing proper documentation of each API and the pre-requirements for execution. But who can guarantee that the documents correctly map the requirements?

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T17:21:53Z

Nmsarda:

<h1>SaaS - 3.7. Mixins and Duck Typing</h1>
This wiki is aimed at acting as a complementary read to the SaaS - 3.7. Mixins and Duck Typing lecture. This lecture describes three of the most important fundamentals of the Ruby language: Duck-Typing, Modules and Mixins.
<h1>Introduction</h1>
Duck-typing is one of the main features of many object-oriented languages. Duck-Typing describes how a language like Ruby, treats its objects as compared to a language like JAVA. We describe the beautiful features of Duck-typing and also its negative side-effects.<br>
Modules define a namespace. It provides a mechanism to club several things together which naturally do-not form a common class. With modules, programmer does not have to worry of possible name-clashes of method name's with other methods written by different programmers. Modules handles this by making use of namespace.<br>
Mixins extend from modules. modules are not classes and hence we cannot instantiate them. However, when modules are 'include'ed in a class, all its methods are available to that class. We say modules are 'mixed in' to the class or in other words 'mixins'. Modules which are mixed in behave as superclass and provide multiple inheritance.

<h1>[http://en.wikipedia.org/wiki/Duck_typing Duck Typing][1]</h1>
<h2>What is Duck Typing</h2>[http://threebrothers.org/brendan/blog/death-by-duck-typing/[[File:Duckt.gif]]][2]
'''“If a object walks like a duck, quacks like a duck then treat it as a duck”'''
This is the ‘mantra’ of Ruby language and the most pleasing aspect of the language. What it means is that, whether an object responds to a method?, is only important and not the type of the object.
If a dragon responds to methods like swim and quacking, ruby is happy to treat dragon as a duck without having a concern of whether it actually is a duck or not. This gives powerful tools for a ruby programmer.

This is possible in Ruby because we don’t declare the '[http://en.wikipedia.org/wiki/Programming_language#Type_system Type][3] of variables or methods like in JAVA; in Ruby, everything is an object and each object can be individually modified, irrespective of its implementation in the class to which it belongs.

Consider the following example taken from the SAAS lecture:
<pre>
my_list.sort

[5, 4, 3].sort
["dog", "cat", "rat"].sort
[:a, :b, :c].sort
</pre>

Here, the same function, sort, is responding to an array of integers, strings and literals. This is classic Ruby duck-typing at work. How sort works is that it compares the elements which are needed to be sorted. So as long as the elements can be compared, sort function works. In the above example, the array of integers, strings and literals implement the comparison operator and hence the same sort function works for all of them.

<h2> Why in Ruby and not in JAVA? </h2>
The reason for duck-typing to be easily possible and implemented in language like Ruby and not in language like JAVA is that these 2 languages treat ‘type’ differently.
In JAVA or C++, type means class. When someone asks the type of “abc”, we say it is String. So, such language allows String objects to refer to only other String objects.
String a; a will never be allowed to refer to anything other than a string, like a=5.

While in Ruby, type refers to how the object reacts to a method or in other words does the object have a particular capability. Type refers to this capability. While a class to which the object belongs provides the initial capabilities, from that point on, the object is free to extend its capabilities independently of its pre-defined class. So,

a= ”abc”
a= 5 are two perfectly acceptable statements in Ruby.

This is duck-typing.

[http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/ A classic example][3] of how a scripting language, JavaScript, not implementing duck-typing can lead to some bad code.

<h2> The other side to Duck-Typing </h2>
As with everything in life, there is always 2 perspectives about its usefulness. Following are some of the criticism against duck-typing :
<h3>Lack of compiler security</h3>
There is no help from compiler for a programmer error like assigning a string to an integer and so on. Only when you run the code, the output might be funny and that’s when you realize a probable mistake in assignment. In a static-type language, there is always a compiler check and hence the problem does not arise. Obviously this problem can be alleviated by proper and exhaustive testing. But as we all know, no one can guarantee 100% code tests.
<h3>Contract between caller and the callee</h3>
In a static type language, the caller knows the exact ‘type’ of parameters required by the callee and also the return-type from the callee. In dynamic type languages, no type is provided. So to understand what the callee expects, one has to look at the code and understand. This is difficult in most of the cases and mainly for third-party code. Again this problem can be solved by providing proper documentation of each API and the pre-requirements for execution. But who can guarantee that the documents correctly map the requirements?

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T17:05:29Z

Nmsarda:

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T17:00:00Z

Nmsarda:

<h1>SaaS - 3.7. Mixins and Duck Typing</h1>

<h2>Introduction</h2>
This wiki is aimed at acting as a complementary read to the SaaS - 3.7. Mixins and Duck Typing lecture. This lecture describes three of the most important fundamentals of the Ruby language. Duck-Typing, Modules and Mixins. Lets look at these cocepts in much more detail in the following sections.

<h2>[http://en.wikipedia.org/wiki/Duck_typing Duck Typing][1]</h2>
<h3>What is Duck Typing</h3>[http://threebrothers.org/brendan/blog/death-by-duck-typing/[[File:Duckt.gif]]][2]
'''“If a object walks like a duck, quacks like a duck then treat it as a duck”'''
This is the ‘mantra’ of Ruby language and the most pleasing aspect of the language. What it means is that, whether an object responds to a method?, is only important and not the type of the object.
If a dragon responds to methods like swim and quacking, ruby is happy to treat dragon as a duck without having a concern of whether it actually is a duck or not. This gives powerful tools for a ruby programmer.

This is possible in Ruby because we don’t declare the '[http://en.wikipedia.org/wiki/Programming_language#Type_system Type][3] of variables or methods like in JAVA; in Ruby, everything is an object and each object can be individually modified, irrespective of its implementation in the class to which it belongs.

Consider the following example taken from the SAAS lecture:
<pre>
my_list.sort

[5, 4, 3].sort
["dog", "cat", "rat"].sort
[:a, :b, :c].sort
</pre>

Here, the same function, sort, is responding to an array of integers, strings and literals. This is classic Ruby duck-typing at work. How sort works is that it compares the elements which are needed to be sorted. So as long as the elements can be compared, sort function works. In the above example, the array of integers, strings and literals implement the comparison operator and hence the same sort function works for all of them.

<h3> Why in Ruby and not in JAVA? </h3>
The reason for duck-typing to be easily possible and implemented in language like Ruby and not in language like JAVA is that these 2 languages treat ‘type’ differently.
In JAVA or C++, type means class. When someone asks the type of “abc”, we say it is String. So, such language allows String objects to refer to only other String objects.
String a; a will never be allowed to refer to anything other than a string, like a=5.

While in Ruby, type refers to how the object reacts to a method or in other words does the object have a particular capability. Type refers to this capability. While a class to which the object belongs provides the initial capabilities, from that point on, the object is free to extend its capabilities independently of its pre-defined class. So,

a= ”abc”
a= 5 are two perfectly acceptable statements in Ruby.

This is duck-typing.

[http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/ A classic example][3] of how a scripting language, JavaScript, not implementing duck-typing can lead to some bad code.

<h3> The other side to Duck-Typing </h3>
As with everything in life, there is always 2 perspectives about its usefulness. Following are some of the criticism against duck-typing :
<h4>Lack of compiler security</h4>
There is no help from compiler for a programmer error like assigning a string to an integer and so on. Only when you run the code, the output might be funny and that’s when you realize a probable mistake in assignment. In a static-type language, there is always a compiler check and hence the problem does not arise. Obviously this problem can be alleviated by proper and exhaustive testing. But as we all know, no one can guarantee 100% code tests.
<h4>Contract between caller and the callee</h4>
In a static type language, the caller knows the exact ‘type’ of parameters required by the callee and also the return-type from the callee. In dynamic type languages, no type is provided. So to understand what the callee expects, one has to look at the code and understand. This is difficult in most of the cases and mainly for third-party code. Again this problem can be solved by providing proper documentation of each API and the pre-requirements for execution. But who can guarantee that the documents correctly map the requirements?

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T08:11:53Z

Nmsarda:

<h1>SaaS - 3.7. Mixins and Duck Typing</h1>

<h1>[http://en.wikipedia.org/wiki/Duck_typing Duck Typing][1]</h1>
<h2>What is Duck Typing</h2>[http://threebrothers.org/brendan/blog/death-by-duck-typing/[[File:Duckt.gif]]][2]
'''“If a object walks like a duck, quacks like a duck then treat it as a duck”'''
This is the ‘mantra’ of Ruby language and the most pleasing aspect of the language. What it means is that, whether an object responds to a method?, is only important and not the type of the object.
If a dragon responds to methods like swim and quacking, ruby is happy to treat dragon as a duck without having a concern of whether it actually is a duck or not. This gives powerful tools for a ruby programmer.

This is possible in Ruby because we don’t declare the '[http://en.wikipedia.org/wiki/Programming_language#Type_system Type][3] of variables or methods like in JAVA; in Ruby, everything is an object and each object can be individually modified, irrespective of its implementation in the class to which it belongs.

Consider the following example taken from the SAAS lecture:
<pre>
my_list.sort

[5, 4, 3].sort
["dog", "cat", "rat"].sort
[:a, :b, :c].sort
</pre>

Here, the same function, sort, is responding to an array of integers, strings and literals. This is classic Ruby duck-typing at work. How sort works is that it compares the elements which are needed to be sorted. So as long as the elements can be compared, sort function works. In the above example, the array of integers, strings and literals implement the comparison operator and hence the same sort function works for all of them.

<h2> Why in Ruby and not in JAVA? </h2>
The reason for duck-typing to be easily possible and implemented in language like Ruby and not in language like JAVA is that these 2 languages treat ‘type’ differently.
In JAVA or C++, type means class. When someone asks the type of “abc”, we say it is String. So, such language allows String objects to refer to only other String objects.
String a; a will never be allowed to refer to anything other than a string, like a=5.

While in Ruby, type refers to how the object reacts to a method or in other words does the object have a particular capability. Type refers to this capability. While a class to which the object belongs provides the initial capabilities, from that point on, the object is free to extend its capabilities independently of its pre-defined class. So,

a= ”abc”
a= 5 are two perfectly acceptable statements in Ruby.

This is duck-typing.

[http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/ A classic example][3] of how a scripting language, JavaScript, not implementing duck-typing can lead to some bad code.

<h2> The other side to Duck-Typing </h2>
As with everything in life, there is always 2 perspectives about its usefulness. Following are some of the criticism against duck-typing :
<h3>Lack of compiler security</h3>
There is no help from compiler for a programmer error like assigning a string to an integer and so on. Only when you run the code, the output might be funny and that’s when you realize a probable mistake in assignment. In a static-type language, there is always a compiler check and hence the problem does not arise. Obviously this problem can be alleviated by proper and exhaustive testing. But as we all know, no one can guarantee 100% code tests.
<h3>Contract between caller and the callee</h3>
In a static type language, the caller knows the exact ‘type’ of parameters required by the callee and also the return-type from the callee. In dynamic type languages, no type is provided. So to understand what the callee expects, one has to look at the code and understand. This is difficult in most of the cases and mainly for third-party code. Again this problem can be solved by providing proper documentation of each API and the pre-requirements for execution. But who can guarantee that the documents correctly map the requirements?

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T08:11:24Z

Nmsarda:

<h1>SaaS - 3.7. Mixins and Duck Typing[1]</h1>

<h1>[http://en.wikipedia.org/wiki/Duck_typing Duck Typing]</h1>
<h2>What is Duck Typing</h2>[http://threebrothers.org/brendan/blog/death-by-duck-typing/[[File:Duckt.gif]]][2]
'''“If a object walks like a duck, quacks like a duck then treat it as a duck”'''
This is the ‘mantra’ of Ruby language and the most pleasing aspect of the language. What it means is that, whether an object responds to a method?, is only important and not the type of the object.
If a dragon responds to methods like swim and quacking, ruby is happy to treat dragon as a duck without having a concern of whether it actually is a duck or not. This gives powerful tools for a ruby programmer.

This is possible in Ruby because we don’t declare the '[http://en.wikipedia.org/wiki/Programming_language#Type_system Type][3] of variables or methods like in JAVA; in Ruby, everything is an object and each object can be individually modified, irrespective of its implementation in the class to which it belongs.

Consider the following example taken from the SAAS lecture:
<pre>
my_list.sort

[5, 4, 3].sort
["dog", "cat", "rat"].sort
[:a, :b, :c].sort
</pre>

Here, the same function, sort, is responding to an array of integers, strings and literals. This is classic Ruby duck-typing at work. How sort works is that it compares the elements which are needed to be sorted. So as long as the elements can be compared, sort function works. In the above example, the array of integers, strings and literals implement the comparison operator and hence the same sort function works for all of them.

<h2> Why in Ruby and not in JAVA? </h2>
The reason for duck-typing to be easily possible and implemented in language like Ruby and not in language like JAVA is that these 2 languages treat ‘type’ differently.
In JAVA or C++, type means class. When someone asks the type of “abc”, we say it is String. So, such language allows String objects to refer to only other String objects.
String a; a will never be allowed to refer to anything other than a string, like a=5.

While in Ruby, type refers to how the object reacts to a method or in other words does the object have a particular capability. Type refers to this capability. While a class to which the object belongs provides the initial capabilities, from that point on, the object is free to extend its capabilities independently of its pre-defined class. So,

a= ”abc”
a= 5 are two perfectly acceptable statements in Ruby.

This is duck-typing.

[http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/ A classic example][3] of how a scripting language, JavaScript, not implementing duck-typing can lead to some bad code.

<h2> The other side to Duck-Typing </h2>
As with everything in life, there is always 2 perspectives about its usefulness. Following are some of the criticism against duck-typing :
<h3>Lack of compiler security</h3>
There is no help from compiler for a programmer error like assigning a string to an integer and so on. Only when you run the code, the output might be funny and that’s when you realize a probable mistake in assignment. In a static-type language, there is always a compiler check and hence the problem does not arise. Obviously this problem can be alleviated by proper and exhaustive testing. But as we all know, no one can guarantee 100% code tests.
<h3>Contract between caller and the callee</h3>
In a static type language, the caller knows the exact ‘type’ of parameters required by the callee and also the return-type from the callee. In dynamic type languages, no type is provided. So to understand what the callee expects, one has to look at the code and understand. This is difficult in most of the cases and mainly for third-party code. Again this problem can be solved by providing proper documentation of each API and the pre-requirements for execution. But who can guarantee that the documents correctly map the requirements?

File:Duckt.gif

2012-11-18T08:07:27Z

Nmsarda: Duck

Duck

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T08:03:45Z

Nmsarda:

<h1>SaaS - 3.7. Mixins and Duck Typing[1]</h1>

<h1>[http://en.wikipedia.org/wiki/Duck_typing Duck Typing]</h1>
<h2>What is Duck Typing</h2>
'''“If a object walks like a duck, quacks like a duck then treat it as a duck”'''
This is the ‘mantra’ of Ruby language and the most pleasing aspect of the language. What it means is that, whether an object responds to a method?, is only important and not the type of the object.
If a dragon responds to methods like swim and quacking, ruby is happy to treat dragon as a duck without having a concern of whether it actually is a duck or not. This gives powerful tools for a ruby programmer.

This is possible in Ruby because we don’t declare the '[http://en.wikipedia.org/wiki/Programming_language#Type_system Type][2] of variables or methods like in JAVA; in Ruby, everything is an object and each object can be individually modified, irrespective of its implementation in the class to which it belongs.

Consider the following example taken from the SAAS lecture:
<pre>
my_list.sort

[5, 4, 3].sort
["dog", "cat", "rat"].sort
[:a, :b, :c].sort
</pre>

Here, the same function, sort, is responding to an array of integers, strings and literals. This is classic Ruby duck-typing at work. How sort works is that it compares the elements which are needed to be sorted. So as long as the elements can be compared, sort function works. In the above example, the array of integers, strings and literals implement the comparison operator and hence the same sort function works for all of them.

<h2> Why in Ruby and not in JAVA? </h2>
The reason for duck-typing to be easily possible and implemented in language like Ruby and not in language like JAVA is that these 2 languages treat ‘type’ differently.
In JAVA or C++, type means class. When someone asks the type of “abc”, we say it is String. So, such language allows String objects to refer to only other String objects.
String a; a will never be allowed to refer to anything other than a string, like a=5.

While in Ruby, type refers to how the object reacts to a method or in other words does the object have a particular capability. Type refers to this capability. While a class to which the object belongs provides the initial capabilities, from that point on, the object is free to extend its capabilities independently of its pre-defined class. So,

a= ”abc”
a= 5 are two perfectly acceptable statements in Ruby.

This is duck-typing.

[http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/ A classic example][3] of how a scripting language, JavaScript, not implementing duck-typing can lead to some bad code.

<h2> The other side to Duck-Typing </h2>
As with everything in life, there is always 2 perspectives about its usefulness. Following are some of the criticism against duck-typing :
<h3>Lack of compiler security</h3>
There is no help from compiler for a programmer error like assigning a string to an integer and so on. Only when you run the code, the output might be funny and that’s when you realize a probable mistake in assignment. In a static-type language, there is always a compiler check and hence the problem does not arise. Obviously this problem can be alleviated by proper and exhaustive testing. But as we all know, no one can guarantee 100% code tests.
<h3>Contract between caller and the callee</h3>
In a static type language, the caller knows the exact ‘type’ of parameters required by the callee and also the return-type from the callee. In dynamic type languages, no type is provided. So to understand what the callee expects, one has to look at the code and understand. This is difficult in most of the cases and mainly for third-party code. Again this problem can be solved by providing proper documentation of each API and the pre-requirements for execution. But who can guarantee that the documents correctly map the requirements?

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T07:13:52Z

Nmsarda:

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T07:12:27Z

Nmsarda:

<h1>SaaS - 3.7. Mixins and Duck Typing</h1>

<h1>[http://en.wikipedia.org/wiki/Duck_typing Duck Typing]</h1>[1]
<h2>What is Duck Typing</h2>
'''“If a object walks like a duck, quacks like a duck then treat it as a duck”'''
This is the ‘mantra’ of Ruby language and the most pleasing aspect of the language. What it means is that, whether an object responds to a method?, is only important and not the type of the object.
If a dragon responds to methods like swim and quacking, ruby is happy to treat dragon as a duck without having a concern of whether it actually is a duck or not. This gives powerful tools for a ruby programmer.

This is possible in Ruby because we don’t declare the '[http://en.wikipedia.org/wiki/Programming_language#Type_system Type][2] of variables or methods like in JAVA; in Ruby, everything is an object and each object can be individually modified, irrespective of its implementation in the class to which it belongs.

Consider the following example taken from the SAAS lecture:
<pre>
my_list.sort

[5, 4, 3].sort
["dog", "cat", "rat"].sort
[:a, :b, :c].sort
</pre>

Here, the same function, sort, is responding to an array of integers, strings and literals. This is classic Ruby duck-typing at work. How sort works is that it compares the elements which are needed to be sorted. So as long as the elements can be compared, sort function works. In the above example, the array of integers, strings and literals implement the comparison operator and hence the same sort function works for all of them.

<h2> Why in Ruby and not in JAVA? </h2>
The reason for duck-typing to be easily possible and implemented in language like Ruby and not in language like JAVA is that these 2 languages treat ‘type’ differently.
In JAVA or C++, type means class. When someone asks the type of “abc”, we say it is String. So, such language allows String objects to refer to only other String objects.
String a; a will never be allowed to refer to anything other than a string, like a=5.

While in Ruby, type refers to how the object reacts to a method or in other words does the object have a particular capability. Type refers to this capability. While a class to which the object belongs provides the initial capabilities, from that point on, the object is free to extend its capabilities independently of its pre-defined class. So,

a= ”abc”
a= 5 are two perfectly acceptable statements in Ruby.

This is duck-typing.

[http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/ A classic example][3] of how a scripting language, JavaScript, not implementing duck-typing can lead to some bad code.

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T07:11:46Z

Nmsarda:

<h1>SaaS - 3.7. Mixins and Duck Typing</h1>

<h1>[http://en.wikipedia.org/wiki/Duck_typing Duck Typing][1]</h1>
<h2>What is Duck Typing</h2>
'''“If a object walks like a duck, quacks like a duck then treat it as a duck”'''
This is the ‘mantra’ of Ruby language and the most pleasing aspect of the language. What it means is that, whether an object responds to a method?, is only important and not the type of the object.
If a dragon responds to methods like swim and quacking, ruby is happy to treat dragon as a duck without having a concern of whether it actually is a duck or not. This gives powerful tools for a ruby programmer.

This is possible in Ruby because we don’t declare the '[http://en.wikipedia.org/wiki/Programming_language#Type_system Type][2] of variables or methods like in JAVA; in Ruby, everything is an object and each object can be individually modified, irrespective of its implementation in the class to which it belongs.

Consider the following example taken from the SAAS lecture:
<pre>
my_list.sort

[5, 4, 3].sort
["dog", "cat", "rat"].sort
[:a, :b, :c].sort
</pre>

Here, the same function, sort, is responding to an array of integers, strings and literals. This is classic Ruby duck-typing at work. How sort works is that it compares the elements which are needed to be sorted. So as long as the elements can be compared, sort function works. In the above example, the array of integers, strings and literals implement the comparison operator and hence the same sort function works for all of them.

<h2> Why in Ruby and not in JAVA? </h2>
The reason for duck-typing to be easily possible and implemented in language like Ruby and not in language like JAVA is that these 2 languages treat ‘type’ differently.
In JAVA or C++, type means class. When someone asks the type of “abc”, we say it is String. So, such language allows String objects to refer to only other String objects.
String a; a will never be allowed to refer to anything other than a string, like a=5.

While in Ruby, type refers to how the object reacts to a method or in other words does the object have a particular capability. Type refers to this capability. While a class to which the object belongs provides the initial capabilities, from that point on, the object is free to extend its capabilities independently of its pre-defined class. So,

a= ”abc”
a= 5 are two perfectly acceptable statements in Ruby.

This is duck-typing.

[http://bigdingus.com/2007/12/08/just-what-is-this-javascript-object-you-handed-me/ A classic example][3] of how a scripting language, JavaScript, not implementing duck-typing can lead to some bad code.

CSC/ECE 517 Fall 2012/ch2b 1w59 nm

2012-11-18T06:56:08Z

Nmsarda: Created page with "<h1>SaaS - 3.7. Mixins and Duck Typing</h1>"

<h1>SaaS - 3.7. Mixins and Duck Typing</h1>

CSC/ECE 517 Fall 2012/ch1b 1w38 nm

2012-10-04T02:20:24Z

Nmsarda:

<h1>Introduction</h1>
This page is aimed at asserting the importance of Model View Controller Architecture and how MVC is implemented in Cookbook application.

<h2>Model View Controller (MVC) Architecture</h2>

The purpose of creating MVC architecture is to have clear separation between the responsibilities of business logic and representation. In a nutshell the responsibilities are mentioned as below:

[[File:MVC.png|frame|none|MVC Responsibilities[8]]]

Model-View-Controller (MVC)[1] is an architectural pattern used in software engineering.In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface.<br>
The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. Having described the responsibilities of three components let’s take a look how these components interact with each other.

[[File:MVC_architecture.PNG|frame|none|MVC Architecture[9]]]

<h2>Ruby on Rails</h2>

Ruby on Rails[2] is an MVC framework. Rails enforces a structure for application, it helps to knit the models, views, and controllers as separate chunks of functionality while the program executes. No more external configuration needed. Rails is packed with features that make you more productive, with many of the following features building on one other.<br>
<b>Metaprogramming[7]:</b> Other frameworks use extensive code generation from scratch. Metaprogramming techniques use programs to write programs. Ruby is one of the best languages for metaprogramming, and Rails uses this capability well. Rails also uses code generation but relies much more on metaprogramming for the heavy lifting.<br>
<b>Active Record[6]:</b> Rails introduces the Active Record framework, which saves objects to the database. The Rails version of Active Record discovers the columns in a database schema and automatically attaches them to your domain objects using metaprogramming.<br>
<b>Convention over configuration:</b> Most web development frameworks for .NET or Java force you to write pages of configuration code. If you follow suggested naming conventions, Rails doesn't need much configuration.<br>
<b>Scaffolding:</b> You often create temporary code in the early stages of development to help get an application up quickly and see how major components work together. Rails automatically creates much of the scaffolding you'll need.<br>
<b>Built-in testing:</b> Rails creates simple automated tests which you can extend. Rails also provides supporting code called harnesses and fixtures that make test cases easier to write and run. Ruby can then execute all your automated tests with the rake utility.<br>
<b>Three environments:</b> Rails gives you three default environments: development, testing, and production. Each behaves slightly differently, making your entire software development cycle easier. For example, Rails creates a fresh copy of the Test database for each test run.

<h1>Cookbook Application</h1>
Cookbook Application is a very basic Ruby on Rails application. It is a great way to understand the nuances that ‘Ruby’ has to offer. It is built keeping in mind that the reader is new to the world of ruby and is developing his/her first Ruby on Rails application.
The motive of this wiki page is to make the reader understand how the Cookbook application was built. And on the way to building this application, user will be introduced to some key concepts like Model, Views and Controllers. At the end of this page, reader must fairly be ready to start building his/her basic Ruby on Rails application.

In the Cookbook application we are considering a Cookbook which contains recipes for various dishes. The recipes have been divided into different categories, for example there is a recipe for ice tea which belongs to the category of beverages. There is a relationship which is created between a recipe and a category which can be expressed as an ice tea belongs to beverages. We can have many such recipes belonging to a single category, in this case many to one relationship is established.

<h2>A simple application to start -- Cookbook application</h2>

Start a new project. While creating a new project, remember to select Rails Application option as follows

[[File:Start_application.png|frame|none|Start a new Application]]

When we create a Rails application, it automatically creates a bunch of files and folders as follows:

[[File:Listing_of_cookbook_application.png|frame|none|Listing_of_cookbook_application]]

We mainly use the app directory. This is where the heart of the application is stored i.e. Models, Views and controllers.

<h2>Using scaffold to create framework</h2>
Rails scaffolding is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job.<br>
In Rubymine, we can create a scaffold by right clicking on the current Project->New->Run Rails Generator ->scaffold. This will open a dialog box to create a scaffold where we can enter the name and the attributes along with their data type. Once the scaffold has been created RubyMine will generate the model, view and controller files respectively. These files do not contain any specific methods but they provide a framework which is useful for general applications. The user can modify the MVC behavior according to his/her application requirements. Each scaffold has create, read, update and delete methods declared in the controller class. A user can modify the behavior of the controller through these methods.
<br>

[[File:Create_Scaffold.png|frame|none|Creating a new scaffold]]<br><br>
[[File:Scaffold.png|frame|left|Scaffold]] [[File:New_Scaffold_Categories.png|frame|center|Creating scaffold for categories]]<br>

<h2>Working without scaffold</h2>

Or you don't want to create a fully standard framework with scaffold, then you can use RubyMine generate command to create model, controller and view individually. There are additional commands included in the generate command to create migration, assets, intergration_test and performance_test.
[[File:Generating_controller.png|frame|none|Generating Controller]]
[[File:Generating_controller_recipes.png|frame|none|Generating Recipes controller]]

By clicking on the 'Add' button, we can add the required actions in the controller
Similarly models and views can be created.

<h1>Controllers for Cookbook Application</h1>
The Cookbook application starts by entering a URL in the browser which sends the request to the web server. Since our web server supports Rails application, it will hand over the control to a Rails controller.
A controller ‘controls’ the entire application by responding to the incoming requests as needed. For example, consider the following URL http ://localhost:3000/categories/show which is decoded by the controller to know that its action named show has been invoked.
All the controllers inherit only the ApplicationController which in turn inherits the ActionController::Base class. ActionContoller module provides the basic support for the controllers in Rails.
In our Cookbook application we generate Categories controller using the scaffold mechanism which populates the controller with the basic methods such as index, create, show, new, edit, update and destroy.
A simple example of index method is as follows:
<pre>
def index
@categories = Category.all

respond_to do |format|
format.html # index.html.erb
format.json { render json: @categories }
end
end

</pre>
In ruby, @ operator is used to declare instance variables. The index method makes use of @categories instance variable which is populated with all the records in the Category table. The respond_to method is used for responding to particular type of request. It contains a block and a variable |format| which determines whether the incoming request should be responded with HTML format (when we are interacting with a user) or JSON format (if we are returning an object).
After executing the code, the controller will render a template of the same name. (For this example, the template is views/categories/index.html.erb).
Similarly the show method is defined as follows:
<pre>
def show
@category = Category.find(params[:id])

respond_to do |format|
format.html # show.html.erb
format.json { render json: @category }
end
end

</pre>
The show method is used to display a particular object. The show method needs to access database to search for the given object. This is done using the find method which takes params[:id] as argument. The params[:id] contains the id or primary key of the object which is passed as a parameter to look up in the database and the result is stored in the instance variable. The result is displayed by rendering the show.html.erb file.<br><br>
<b>Active Record</b><br>
In ruby, a program deals with objects which are mapped into database relational databases. This kind of mapping is facilitated by the Active Record.<br>Active Record maps the Rails classes in to database tables and rails objects into database records.
This makes it easy to perform actions on database tables by invoking the class methods. Another benefit of Active Record is database migration. Migrations can manage the evolution of a schema used by several physical databases. It’s a solution to the common problem of adding a field to make a new feature work in your local database, but being unsure of how to push that change to other developers and to the production server. With migrations, you can describe the transformations in self-contained classes that can be checked into version control systems and executed against another database that might be one, two, or five versions behind. You can find a lot more details about rails migration here[8].
<p>
<b>Method Pairs</b>
<br>There are couple of method pairs such as new-create and edit-update which are executed in sequence. In method pair one method is responsible for display preparation and the other method validates the data and attempts it to save in the database.
<pre>
def new
@category = Category.new

respond_to do |format|
format.html # new.html.erb
format.json { render json: @category }
end

end
</pre>
<pre>
def create
@category = Category.new(params[:category])

respond_to do |format|
if @category.save
format.html { redirect_to @category, notice: 'Category was successfully created.' }
format.json { render json: @category, status: :created, location: @category }
else
format.html { render action: "new" }
format.json { render json: @category.errors, status: :unprocessable_entity }
end
end
end

</pre>

The new method is used to instantiate a new Category object whereas create method is used to successfully save the object to the database. After execution of the new method, the controller renders the new.html.erb file which displays a form to create a new Category object. The user enters the required information in the form and the object id is returned in the URL on when the form is submitted. Consider the following URL which is generated on submitting the form: http: //localhost:3000/categories/3.
This means that a Category object with id = 3 will be created. The details of the object will be processed by the create method.
The controller invokes the create method to store the object in the database. An observation can be made about the @category variable in the create method.
<pre>
@category = Category.new(params[:category])
</pre>
The parameters passed in the URL after creating a new object is stored in the params hash (denoted by params[]). In this case the params[] contains an object with category_id = 3. The params[] assigns the data of object with category_id = 3 to the instance variable. The data entered in the instance variable is validated using the @category.save method. If no errors are found then the object stored in the database and a message on successful creation of the object is displayed to the user. However, if the data entered in the object contains an error, the user is redirected to the new.html.erb page to resubmit the information and the errors are displayed.
Another example of such method pair is the edit and update methods. The edit method displays the table entry for an existing object, while the update method is invoked when the changes have been submitted.
</p>
<p>
<h1>Models of Cookbook Application</h1>
Model handles the data processing in a web application. Actions interact with the model to manipulate the data. Rails is capable of handling databases and this is facilitated by the model. You can base models on the Rails ActiveRecord module which contains support databases.
In our Cookbook application we have two models namely: Category and Recipe. They are represented by files category.rb and recipe.rb and each file is used to describe the relation between two classes. Let’s take a look at the two models
<br><b> category.rb</b>
<pre>
class Category < ActiveRecord::Base
has_many :recipes
end
</pre>

<b>recipe.rb</b>
<pre>class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>
</p>

*<b>Relationships in models</b>
<ul>one-to-one<br>
<pre>
class Syllabus < ActiveRecord::Base
belongs_to :course¬
end

class Course < ActiveRecord::Base
has_one :syllabus
end
</pre>
</ul>
<ul>many-many<br>
<pre>
class Student < ActiveRecord::Base
has_and_belongs_to_many :courses
end

class Course < ActiveRecord::Base
has_and_belongs_to_many :students
end
</pre></ul>

In Cookbook, we have many-one relationship between recipes and categories.
<p>
<h1>Views of Cookbook application</h1>
What is V in MVC? ‘V’ refers to views. Views are the actual interface that users can see. It is through views, that a user may request some data to be viewed or submits some data for processing.<br>
Views in rails are of the form file_name.html.erb. Here erb means embedded ruby. What html.erb denotes is some ruby code is embedded in HTML code. Like HTML, embedded ruby also uses tags to represent data. However, to distinguish it from the HTML code, ruby is embedded between <% %> if some non-assignment ruby operation is to be performed. If something needs to be displayed on screen, <%= %> is used.
Views are present in “app/views” folder in the rails application.
<br>
Name of the view files is same as the name of their respective controller. For e.g.:- if I have a controller movie with an action new, the corresponding view page will be new.html.erb in the app/views/movie directory.<br>
The Cookbook application views are as follows:

<b> Recipe Controller Views</b><br>
1. index.html.erb
This page is used to display all the recipes that exist in the database.
<pre><nowiki><h1>Listing categories</h1>

<table>
<tr>
<th>Name</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @categories.each do |category| %>
<tr>
<td><%= category.name %></td>
<td><%= link_to 'Show', category %></td>
<td><%= link_to 'Edit', edit_category_path(category) %></td>
<td><%= link_to 'Destroy', category, method: :delete, data: { confirm: 'Are you sure?' } %></td>
</tr>
<% end %>
</table>
<br />

<%= link_to 'New Category', new_category_path %>
</nowiki></pre>

*<b><% @recipes.each do |recipe| %> </b>
Here @recipes is an instance variable of model recipe defined in index action of the controller ‘recipes’. It contains all the recipes currently present in our application. Then each recipe is taken from this instance variable and is assigned to the local variable recipe. All the subsequent lines display the recipe details (name, description and instruction).
<br>
*<b><%= link_to ‘Show’, recipe %> </b>
link_to is an ruby operator which is used to redirect the control to some other page. ‘Show’ is displayed as it is on the page and is an hyperlink. It links to a page pointed by recipe. The path is defined in the routes.rb file.
<br><br>
2. _form.html.erb
<br>
This is a partial. Partials are devices used for breaking the code in smaller, more manageable chunks. This helps in modularity and also maintain DRY principle[4]. With a partial, code for rendering a particular response is moved to its own file. So for e.g. we can use this same partial for creating and editing information, because the information involved is essentially the same.
<pre>
<%= form_for(@recipe) do |f| %>
<% if @recipe.errors.any? %>
<div id="error_explanation">
<h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>

<ul>
<% @recipe.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>

<div class="field">
<%= f.label :name %><br />
<%= f.text_field :name %>
</div>
<%= f.label :category %>
<%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %>
<div class="field">
<%= f.label :description %><br />
<%= f.text_field :description %>
</div>
<div class="field">
<%= f.label :instructions %><br />
<%= f.text_area :instructions %>
<%= f.submit %>
</div>
<% end %>
</pre>

* <b><%= form_for(@recipe) do |f| %></b>
This statement means to render a form for the instance variable @recipe.
If this page is being used for creating a new recipe, then the values for each key in the @recipe hash will be empty. If it is used for editing a recipe, @recipe will contain information corresponding to the recipe being edited.

*<b><% if @recipe.errors.any? %></b>
While saving an recipe or updating a recipe in the database, some violations may occur. Like the recipe name is left empty or its description is empty and so on. So while saving this information, database will signal some error. The errors are sent back to this page and are caught in @recipe.errors.any? statement.

*<b><%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %></b>
This statement creates a dropdown box.<br>
<ul>‘recipe’ : refers to the object to which the selected value is to be assigned. In this case , it is the recipe object</ul>
<ul>‘category_id’ : create a ‘category_id’ key in the recipe hash.</ul>
<ul>Category.all.collect {|c| [c[:name],c[:id]]} : recover all categories from the database and list them in the dropdown box. The value for each name is c[:id]. Whenever a category is selected by the user, its corresponding id is assigned to the ‘category_id’ key in the ‘recipe’ object.</ul>
<br>
3. new.html.erb<br>
This page is used to create a new recipe. This page simply renders the partial described above.
<pre>
<h1>New recipe</h1>
<%= render 'form' %>
<%= link_to 'Back', recipes_path %>
</pre>
*<b><%= render ‘form’ %> </b>
This statement renders the partial.
<br>
4. edit.html.erb
This page is used to edit a existing recipe. This page also renders the partial.
<pre>
<h1>Editing recipe</h1>
<%= render 'form' %>
<%= link_to 'Show', @recipe %> |
<%= link_to 'Back', recipes_path %>
</pre>
5. show.html.erb
This page is used to show a particular recipe requested by the user. The recipe requested is captured by the controller in the @recipe instance variable and is passed to this view.
<pre>
<p id="notice"><%= notice %></p>
<p>
<b>Name:</b>
<%= @recipe.name %>
</p>
<p>
<b>Description:</b>
<%= @recipe.description %>
</p>
<p>
<b>Instructions:</b>
<%= @recipe.instructions %>
</p>
<%= link_to 'Edit', edit_recipe_path(@recipe) %> |
<%= link_to 'Back', recipes_path %>
</pre>
<br>
<b>The Category Views are very similar to the recipe Views and can be created similarly.</b>

<h1>Conclusion</h1>

MVC was first proposed by Trygve Reenskaug in 1979. He broke applications into three types of components: models, which is responsible for maintaining the state of the application; views, which are responsible for generating a user interface; and controllers, which orchestrate the applications by receiving events from outside world, interact with model, and display an appropriate view to user. This separation of concerns led to far less computing, and in turn made the code easier to write and maintain.<br>
Using Ruby on Rails, one can implement MVC to build various types of web applications. The Cookbook is an easy starter. Readers can learn the basics of Ruby on Rails from this page.

<h1>References</h1>
*[1] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
*[2] http://en.wikipedia.org/wiki/Ruby_on_Rails
*[3] Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
*[4] http://en.wikipedia.org/wiki/Don't_repeat_yourself
*[5] http://guides.rubyonrails.org/getting_started.html
*[6] http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
*[7] http://en.wikipedia.org/wiki/Metaprogramming
*[8] http://net.tutsplus.com/tutorials/other/mvc-for-noobs/
*[9] Hotzner, S. (2007). Beginnning ruby on rail, Indianapolis: Wiley Publishing Inc
<br><br>

The old wiki can be found here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4d_ch.

CSC/ECE 517 Fall 2012/ch1b 1w38 nm

2012-10-04T02:08:30Z

Nmsarda:

<h1>Introduction</h1>
This page is aimed at asserting the importance of Model View Controller Architecture and how MVC is implemented in Cookbook application.

<h2>Model View Controller (MVC) Architecture</h2>

The purpose of creating MVC architecture is to have clear separation between the responsibilities of business logic and representation. In a nutshell the responsibilities are mentioned as below:

[[File:MVC.png|frame|none|MVC Responsibilities[8]]]

Model-View-Controller (MVC)[1] is an architectural pattern used in software engineering.In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface.<br>
The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. Having described the responsibilities of three components let’s take a look how these components interact with each other.

[[File:MVC_architecture.PNG|frame|none|MVC Architecture[9]]]

<h2>Ruby on Rails</h2>

Ruby on Rails[2] is an MVC framework. Rails enforces a structure for application, it helps to knit the models, views, and controllers as separate chunks of functionality while the program executes. No more external configuration needed. Rails is packed with features that make you more productive, with many of the following features building on one other.<br>
<b>Metaprogramming[7]:</b> Other frameworks use extensive code generation from scratch. Metaprogramming techniques use programs to write programs. Ruby is one of the best languages for metaprogramming, and Rails uses this capability well. Rails also uses code generation but relies much more on metaprogramming for the heavy lifting.<br>
<b>Active Record[6]:</b> Rails introduces the Active Record framework, which saves objects to the database. The Rails version of Active Record discovers the columns in a database schema and automatically attaches them to your domain objects using metaprogramming.<br>
<b>Convention over configuration:</b> Most web development frameworks for .NET or Java force you to write pages of configuration code. If you follow suggested naming conventions, Rails doesn't need much configuration.<br>
<b>Scaffolding:</b> You often create temporary code in the early stages of development to help get an application up quickly and see how major components work together. Rails automatically creates much of the scaffolding you'll need.<br>
<b>Built-in testing:</b> Rails creates simple automated tests which you can extend. Rails also provides supporting code called harnesses and fixtures that make test cases easier to write and run. Ruby can then execute all your automated tests with the rake utility.<br>
<b>Three environments:</b> Rails gives you three default environments: development, testing, and production. Each behaves slightly differently, making your entire software development cycle easier. For example, Rails creates a fresh copy of the Test database for each test run.

<h1>Cookbook Application</h1>
Cookbook Application is a very basic Ruby on Rails application. It is a great way to understand the nuances that ‘Ruby’ has to offer. It is built keeping in mind that the reader is new to the world of ruby and is developing his/her first Ruby on Rails application.
The motive of this wiki page is to make the reader understand how the Cookbook application was built. And on the way to building this application, user will be introduced to some key concepts like Model, Views and Controllers. At the end of this page, reader must fairly be ready to start building his/her basic Ruby on Rails application.

In the Cookbook application we are considering a Cookbook which contains recipes for various dishes. The recipes have been divided into different categories, for example there is a recipe for ice tea which belongs to the category of beverages. There is a relationship which is created between a recipe and a category which can be expressed as an ice tea belongs to beverages. We can have many such recipes belonging to a single category, in this case many to one relationship is established.

<h2>A simple application to start -- Cookbook application</h2>

Start a new project. While creating a new project, remember to select Rails Application option as follows

[[File:Start_application.png|frame|none|Start a new Application]]

When we create a Rails application, it automatically creates a bunch of files and folders as follows:

[[File:Listing_of_cookbook_application.png|frame|none|Listing_of_cookbook_application]]

We mainly use the app directory. This is where the heart of the application is stored i.e. Models, Views and controllers.

<h2>Using scaffold to create framework</h2>
Rails scaffolding is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job.<br>
In Rubymine, we can create a scaffold by right clicking on the current Project->New->Run Rails Generator ->scaffold. This will open a dialog box to create a scaffold where we can enter the name and the attributes along with their data type. Once the scaffold has been created RubyMine will generate the model, view and controller files respectively. These files do not contain any specific methods but they provide a framework which is useful for general applications. The user can modify the MVC behavior according to his/her application requirements. Each scaffold has create, read, update and delete methods declared in the controller class. A user can modify the behavior of the controller through these methods.
<br>

[[File:Create_Scaffold.png|frame|none|Creating a new scaffold]]<br><br>
[[File:Scaffold.png|frame|left|Scaffold]] [[File:New_Scaffold_Categories.png|frame|center|Creating scaffold for categories]]<br>

<h2>Working without scaffold</h2>

Or you don't want to create a fully standard framework with scaffold, then you can use RubyMine generate command to create model, controller and view individually. There are additional commands included in the generate command to create migration, assets, intergration_test and performance_test.
[[File:Generating_controller.png|frame|none|Generating Controller]]
[[File:Generating_controller_recipes.png|frame|none|Generating Recipes controller]]

By clicking on the 'Add' button, we can add the required actions in the controller
Similarly models and views can be created.

<h1>Controllers for Cookbook Application</h1>
The Cookbook application starts by entering a URL in the browser which sends the request to the web server. Since our web server supports Rails application, it will hand over the control to a Rails controller.
A controller ‘controls’ the entire application by responding to the incoming requests as needed. For example, consider the following URL http ://localhost:3000/categories/show which is decoded by the controller to know that its action named show has been invoked.
All the controllers inherit only the ApplicationController which in turn inherits the ActionController::Base class. ActionContoller module provides the basic support for the controllers in Rails.
In our Cookbook application we generate Categories controller using the scaffold mechanism which populates the controller with the basic methods such as index, create, show, new, edit, update and destroy.
A simple example of index method is as follows:
<pre>
def index
@categories = Category.all

respond_to do |format|
format.html # index.html.erb
format.json { render json: @categories }
end
end

</pre>
In ruby, @ operator is used to declare instance variables. The index method makes use of @categories instance variable which is populated with all the records in the Category table. The respond_to method is used for responding to particular type of request. It contains a block and a variable |format| which determines whether the incoming request should be responded with HTML (when we are interacting with a user) or JSON format (if we are returning an object).
After executing the code, the controller will render a template of the same name. (For this example, the template is views/categories/index.html.erb).
Similarly the show method is defined as follows:
<pre>
def show
@category = Category.find(params[:id])

respond_to do |format|
format.html # show.html.erb
format.json { render json: @category }
end
end

</pre>
The show method is used to display a particular object. The show method needs to access database to search for the given object. This is done using the find method which takes params[:id] as argument. The params[:id] contains the id or primary key of the object which is passed as a parameter to look up in the database and the result is stored in the instance variable. The result is displayed by rendering the show.html.erb file.<br><br>
<b>Active Record</b><br>
In ruby, a program deals with objects which are mapped into database relational databases. This kind of mapping is facilitated by the Active Record.<br>Active Record maps the Rails classes in to database tables and rails objects into database records.
This makes it easy to perform actions on database tables by invoking the class methods. Another benefit of Active Record is database migration. Migrations can manage the evolution of a schema used by several physical databases. It’s a solution to the common problem of adding a field to make a new feature work in your local database, but being unsure of how to push that change to other developers and to the production server. With migrations, you can describe the transformations in self-contained classes that can be checked into version control systems and executed against another database that might be one, two, or five versions behind.You can find a lot more details about rails migration here[8].
<p>
<b>Method Pairs</b>
<br>There are couple of method pairs such as new-create and edit-update which are executed in sequence. In method pair one method is responsible for display preparation and the other method validates the data and attempts it to save in the database.
<pre>
def new
@category = Category.new

respond_to do |format|
format.html # new.html.erb
format.json { render json: @category }
end

end
</pre>
<pre>
def create
@category = Category.new(params[:category])

respond_to do |format|
if @category.save
format.html { redirect_to @category, notice: 'Category was successfully created.' }
format.json { render json: @category, status: :created, location: @category }
else
format.html { render action: "new" }
format.json { render json: @category.errors, status: :unprocessable_entity }
end
end
end

</pre>

The new and create methods are known as method pairs which execute in sequence. The new method is used to instantiate a new Category object whereas create method is used to successfully save the object to the database. After execution of the new method, the controller renders the new.html.erb file which displays a form to create a new Category object. The user enters the required information in the form and the object id is returned in the URL on submitting the form. Consider the following URL is generated on submitting the form: http: //localhost:3000/categories/3.
This means that Category object with id =3 will be created. The details of the object will be processed by the create method.
The controller invokes the create method to store the object in the database. An observation can be made about the @category variable in the create method.
<pre>
@category = Category.new(params[:category])
</pre>
The parameters passed in the URL after creating a new object is stored in the params hash (denoted by params[]). In this case the params[] contains an object with category_id = 3. The params[] assigns the data of object with category_id =3 to the instance variable. The data entered in the instance variable is validated using the @category.save method. If no errors are found then the object stored in the database and a message on successful creation of the object is displayed to the user. However, if the data entered in the object contains an error, the user is redirected to the new.html.erb page to resubmit the information and the errors are displayed.
Another example of such method pair is the edit and update methods. The edit method displays the table entry for an existing object, while the update method is invoked when the changes have been submitted.
</p>
<p>
<h1>Models of Cookbook Application</h1>
Model handles the data processing in a web application. Actions interact with the model to manipulate the data. Rails is capable of handling databases and this is facilitated by the model. You can base models on the Rails ActiveRecord module which contains support databases.
In our Cookbook application we have two models namely: Category and Recipe. They are represented by files category.rb and recipe.rb and each file is used to describe the relation between two classes. Let’s take a look at the two models
<br><b> category.rb</b>
<pre>
class Category < ActiveRecord::Base
has_many :recipes
end
</pre>

<b>recipe.rb</b>
<pre>class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>
</p>

*<b>Relationships in models</b>
<ul>one-to-one<br>
<pre>
class Syllabus < ActiveRecord::Base
belongs_to :course¬
end

class Course < ActiveRecord::Base
has_one :syllabus
end
</pre>
</ul>
<ul>many-many<br>
<pre>
class Student < ActiveRecord::Base
has_and_belongs_to_many :courses
end

class Course < ActiveRecord::Base
has_and_belongs_to_many :students
end
</pre></ul>

In Cookbook, we have many-one relationship between recipes and categories.
<p>
<h1>Views of Cookbook application</h1>
What is V in MVC? ‘V’ refers to views. Views are the actual interface that users can see. It is through views, that a user may request some data to be viewed or submits some data for processing.<br>
Views in rails are of the form file_name.html.erb. Here erb means embedded ruby. What html.erb denotes is some ruby code is embedded in HTML code. Like HTML, embedded ruby also uses tags to represent data. However, to distinguish it from the HTML code, ruby is embedded between <% %> if some non-assignment ruby operation is to be performed. If something needs to be displayed on screen, <%= %> is used.
Views are present in “app/views” folder in the rails application.
<br>
Name of the view files is same as the name of their respective controller. For e.g.:- if I have a controller movie with an action new, the corresponding view page will be new.html.erb in the app/views/movie directory.<br>
The Cookbook application views are as follows:

<b> Recipe Controller Views</b><br>
1. index.html.erb
<pre><nowiki><h1>Listing categories</h1>

<table>
<tr>
<th>Name</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @categories.each do |category| %>
<tr>
<td><%= category.name %></td>
<td><%= link_to 'Show', category %></td>
<td><%= link_to 'Edit', edit_category_path(category) %></td>
<td><%= link_to 'Destroy', category, method: :delete, data: { confirm: 'Are you sure?' } %></td>
</tr>
<% end %>
</table>
<br />

<%= link_to 'New Category', new_category_path %>
</nowiki></pre>

*<b><% @recipes.each do |recipe| %> </b>
Here @recipes is an instance variable of model recipe defined in index action of the controller ‘recipes’. It contains all the recipes currently present in our application. Then each recipe is taken from this instance variable and is assigned to the local variable recipe. All the subsequent lines display the recipe details (name, description and instruction).
<br>
*<b><%= link_to ‘Show’, recipe %> </b>
link_to is an ruby operator which is used to redirect the control to some other page. ‘Show’ is displayed as it is on the page and is an hyperlink. It links to a page pointed by recipe. The path is defined in the routes.rb file.
<br><br>
2. _form.html.erb
<br>
This is a partial. Partials are devices used for breaking the code in smaller, more manageable chunks. This helps in modularity and also maintain DRY principle[4]. With a partial, code for rendering a particular response is moved to its own file. So for e.g. we can use this same partial for creating and editing information, because the information involved is essentially the same.
<pre>
<%= form_for(@recipe) do |f| %>
<% if @recipe.errors.any? %>
<div id="error_explanation">
<h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>

<ul>
<% @recipe.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>

<div class="field">
<%= f.label :name %><br />
<%= f.text_field :name %>
</div>
<%= f.label :category %>
<%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %>
<div class="field">
<%= f.label :description %><br />
<%= f.text_field :description %>
</div>
<div class="field">
<%= f.label :instructions %><br />
<%= f.text_area :instructions %>
<%= f.submit %>
</div>
<% end %>
</pre>

* <b><%= form_for(@recipe) do |f| %></b>
This statement means to render a form for the instance variable @recipe.
If this page is being used for creating a new recipe, then the values for each key in the @recipe hash will be empty. If it is used for editing a recipe, @recipe will contain information corresponding to the recipe being edited.

*<b><% if @recipe.errors.any? %></b>
While saving an recipe or updating a recipe in the database, some violations may occur. Like the recipe name is left empty or its description is empty and so on. So while saving this information, database will signal some error. The errors are sent back to this page and are caught in @recipe.errors.any? statement.

*<b><%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %></b>
This statement creates a dropdown box.<br>
<ul>‘recipe’ : refers to the object to which the selected value is to be assigned. In this case , it is the recipe object</ul>
<ul>‘category_id’ : create a ‘category_id’ key in the recipe hash.</ul>
<ul>Category.all.collect {|c| [c[:name],c[:id]]} : recover all categories from the database and list them in the dropdown box. The value for each name is c[:id]. Whenever a category is selected by the user, its corresponding id is assigned to the ‘category_id’ key in the ‘recipe’ object.</ul>
<br>
3. new.html.erb<br>
This page is used to create a new recipe. This page simply renders the partial described above.
<pre>
<h1>New recipe</h1>
<%= render 'form' %>
<%= link_to 'Back', recipes_path %>
</pre>
*<b><%= render ‘form’ %> </b>
This statement renders the partial.
<br>
4. edit.html.erb
This page is used to edit a existing recipe. This page also renders the partial.
<pre>
<h1>Editing recipe</h1>
<%= render 'form' %>
<%= link_to 'Show', @recipe %> |
<%= link_to 'Back', recipes_path %>
</pre>
5. show.html.erb
This page is used to show a particular recipe requested by the user. The recipe requested is captured by the controller in the @recipe instance variable and is passed to this view.
<pre>
<p id="notice"><%= notice %></p>
<p>
<b>Name:</b>
<%= @recipe.name %>
</p>
<p>
<b>Description:</b>
<%= @recipe.description %>
</p>
<p>
<b>Instructions:</b>
<%= @recipe.instructions %>
</p>
<%= link_to 'Edit', edit_recipe_path(@recipe) %> |
<%= link_to 'Back', recipes_path %>
</pre>
<br>
<b>The Category Views are very similar to the recipe Views and can be created similarly.</b>

<h1>Conclusion</h1>

MVC was first proposed by Trygve Reenskaug in 1979. He broke applications into three types of components: models, which is responsible for maintaining the state of the application; views, which are responsible for generating a user interface; and controllers, which orchestrate the applications by receiving events from outside world, interact with model, and display an appropriate view to user. This separation of concerns led to far less computing, and in turn made the code easier to write and maintain.<br>
Use Ruby on Rails can implement MVC to build various types of web applications. The Cookbook is an easy starter. Readers can learn the basics of Ruby on Rails from this page.

<h1>References</h1>
*[1] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
*[2] http://en.wikipedia.org/wiki/Ruby_on_Rails
*[3] Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
*[4] http://en.wikipedia.org/wiki/Don't_repeat_yourself
*[5] http://guides.rubyonrails.org/getting_started.html
*[6] http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
*[7] http://en.wikipedia.org/wiki/Metaprogramming
*[8] http://net.tutsplus.com/tutorials/other/mvc-for-noobs/
*[9] Hotzner, S. (2007). Beginnning ruby on rail, Indianapolis: Wiley Publishing Inc
<br><br>

The old wiki can be found here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4d_ch.

File:Generating controller recipes.png

2012-10-04T02:04:43Z

Nmsarda:

File:Generating controller.png

2012-10-04T02:04:01Z

Nmsarda: uploaded a new version of "File:Generating controller.png"

File:Generating controller.png

2012-10-04T02:02:07Z

Nmsarda:

CSC/ECE 517 Fall 2012/ch1b 1w38 nm

2012-10-04T02:01:46Z

Nmsarda:

<h1>Introduction</h1>
This page is aimed at asserting the importance of Model View Controller Architecture and how MVC is implemented in Cookbook application.

<h2>Model View Controller (MVC) Architecture</h2>

The purpose of creating MVC architecture is to have clear separation between the responsibilities of business logic and representation. In a nutshell the responsibilities are mentioned as below:

[[File:MVC.png|frame|none|MVC Responsibilities[8]]]

Model-View-Controller (MVC)[1] is an architectural pattern used in software engineering.In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface.<br>
The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. Having described the responsibilities of three components let’s take a look how these components interact with each other.

[[File:MVC_architecture.PNG|frame|none|MVC Architecture[9]]]

<h2>Ruby on Rails</h2>

Ruby on Rails[2] is an MVC framework. Rails enforces a structure for application, it helps to knit the models, views, and controllers as separate chunks of functionality while the program executes. No more external configuration needed. Rails is packed with features that make you more productive, with many of the following features building on one other.<br>
<b>Metaprogramming[7]:</b> Other frameworks use extensive code generation from scratch. Metaprogramming techniques use programs to write programs. Ruby is one of the best languages for metaprogramming, and Rails uses this capability well. Rails also uses code generation but relies much more on metaprogramming for the heavy lifting.<br>
<b>Active Record[6]:</b> Rails introduces the Active Record framework, which saves objects to the database. The Rails version of Active Record discovers the columns in a database schema and automatically attaches them to your domain objects using metaprogramming.<br>
<b>Convention over configuration:</b> Most web development frameworks for .NET or Java force you to write pages of configuration code. If you follow suggested naming conventions, Rails doesn't need much configuration.<br>
<b>Scaffolding:</b> You often create temporary code in the early stages of development to help get an application up quickly and see how major components work together. Rails automatically creates much of the scaffolding you'll need.<br>
<b>Built-in testing:</b> Rails creates simple automated tests which you can extend. Rails also provides supporting code called harnesses and fixtures that make test cases easier to write and run. Ruby can then execute all your automated tests with the rake utility.<br>
<b>Three environments:</b> Rails gives you three default environments: development, testing, and production. Each behaves slightly differently, making your entire software development cycle easier. For example, Rails creates a fresh copy of the Test database for each test run.

<h1>Cookbook Application</h1>
Cookbook Application is a very basic Ruby on Rails application. It is a great way to understand the nuances that ‘Ruby’ has to offer. It is built keeping in mind that the reader is new to the world of ruby and is developing his/her first Ruby on Rails application.
The motive of this wiki page is to make the reader understand how the Cookbook application was built. And on the way to building this application, user will be introduced to some key concepts like Model, Views and Controllers. At the end of this page, reader must fairly be ready to start building his/her basic Ruby on Rails application.

<h2>A simple application to start -- Cookbook application</h2>

Start a new project. While creating a new project, remember to select Rails Application option as follows

[[File:Start_application.png|frame|none|Start a new Application]]

When we create a Rails application, it automatically creates a bunch of files and folders as follows:

[[File:Listing_of_cookbook_application.png|frame|none|Listing_of_cookbook_application]]

We mainly use the app directory. This is where the heart of the application is stored i.e. Models, Views and controllers.

<h2>Using scaffold to create framework</h2>
Rails scaffolding is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job.<br>
In Rubymine, we can create a scaffold by right clicking on the current Project->New->Run Rails Generator ->scaffold. This will open a dialog box to create a scaffold where we can enter the name and the attributes along with their data type. Once the scaffold has been created RubyMine will generate the model, view and controller files respectively. These files do not contain any specific methods but they provide a framework which is useful for general applications. The user can modify the MVC behavior according to his/her application requirements. Each scaffold has create, read, update and delete methods declared in the controller class. A user can modify the behavior of the controller through these methods.
<br>

[[File:Create_Scaffold.png|frame|none|Creating a new scaffold]]<br><br>
[[File:Scaffold.png|frame|left|Scaffold]] [[File:New_Scaffold_Categories.png|frame|center|Creating scaffold for categories]]<br>

<h2>Working without scaffold</h2>

Or you don't want to create a fully standard framework with scaffold, then you can use RubyMine generate command to create model, controller and view individually. There are additional commands included in the generate command to create migration, assets, intergration_test and performance_test.

[[File:Generating_controller.png|frame|left|Generating Controller]] [[File:Generating_controller_recipes.png|frame|left|Generating Recipes controller]]

In the Cookbook application we are considering a Cookbook which contains recipes for various dishes. The recipes have been divided into different categories, for example there is a recipe for ice tea which belongs to the category of beverages. There is a relationship which is created between a recipe and a category which can be expressed as an ice tea belongs to beverages. We can have many such recipes belonging to a single category, in this case many to one relationship is established.

<h1>Controllers for Cookbook Application</h1>
The Cookbook application starts by entering a URL in the browser which sends the request to the web server. Since our web server supports Rails application, it will hand over the control to a Rails controller.
A controller ‘controls’ the entire application by responding to the incoming requests as needed. For example, consider the following URL http ://localhost:3000/categories/show which is decoded by the controller to know that its action named show has been invoked.
All the controllers inherit only the ApplicationController which in turn inherits the ActionController::Base class. ActionContoller module provides the basic support for the controllers in Rails.
In our Cookbook application we generate Categories controller using the scaffold mechanism which populates the controller with the basic methods such as index, create, show, new, edit, update and destroy.
A simple example of index method is as follows:
<pre>
def index
@categories = Category.all

respond_to do |format|
format.html # index.html.erb
format.json { render json: @categories }
end
end

</pre>
In ruby, @ operator is used to declare instance variables. The index method makes use of @categories instance variable which is populated with all the records in the Category table. The respond_to method is used for responding to particular type of request. It contains a block and a variable |format| which determines whether the incoming request should be responded with HTML (when we are interacting with a user) or JSON format (if we are returning an object).
After executing the code, the controller will render a template of the same name. (For this example, the template is views/categories/index.html.erb).
Similarly the show method is defined as follows:
<pre>
def show
@category = Category.find(params[:id])

respond_to do |format|
format.html # show.html.erb
format.json { render json: @category }
end
end

</pre>
The show method is used to display a particular object. The show method needs to access database to search for the given object. This is done using the find method which takes params[:id] as argument. The params[:id] contains the id or primary key of the object which is passed as a parameter to look up in the database and the result is stored in the instance variable. The result is displayed by rendering the show.html.erb file.<br><br>
<b>Active Record</b><br>
In ruby, a program deals with objects which are mapped into database relational databases. This kind of mapping is facilitated by the Active Record.<br>Active Record maps the Rails classes in to database tables and rails objects into database records.
This makes it easy to perform actions on database tables by invoking the class methods. Another benefit of Active Record is database migration. Migrations can manage the evolution of a schema used by several physical databases. It’s a solution to the common problem of adding a field to make a new feature work in your local database, but being unsure of how to push that change to other developers and to the production server. With migrations, you can describe the transformations in self-contained classes that can be checked into version control systems and executed against another database that might be one, two, or five versions behind.You can find a lot more details about rails migration here[8].
<p>
<b>Method Pairs</b>
<br>There are couple of method pairs such as new-create and edit-update which are executed in sequence. In method pair one method is responsible for display preparation and the other method validates the data and attempts it to save in the database.
<pre>
def new
@category = Category.new

respond_to do |format|
format.html # new.html.erb
format.json { render json: @category }
end

end
</pre>
<pre>
def create
@category = Category.new(params[:category])

respond_to do |format|
if @category.save
format.html { redirect_to @category, notice: 'Category was successfully created.' }
format.json { render json: @category, status: :created, location: @category }
else
format.html { render action: "new" }
format.json { render json: @category.errors, status: :unprocessable_entity }
end
end
end

</pre>

The new and create methods are known as method pairs which execute in sequence. The new method is used to instantiate a new Category object whereas create method is used to successfully save the object to the database. After execution of the new method, the controller renders the new.html.erb file which displays a form to create a new Category object. The user enters the required information in the form and the object id is returned in the URL on submitting the form. Consider the following URL is generated on submitting the form: http: //localhost:3000/categories/3.
This means that Category object with id =3 will be created. The details of the object will be processed by the create method.
The controller invokes the create method to store the object in the database. An observation can be made about the @category variable in the create method.
<pre>
@category = Category.new(params[:category])
</pre>
The parameters passed in the URL after creating a new object is stored in the params hash (denoted by params[]). In this case the params[] contains an object with category_id = 3. The params[] assigns the data of object with category_id =3 to the instance variable. The data entered in the instance variable is validated using the @category.save method. If no errors are found then the object stored in the database and a message on successful creation of the object is displayed to the user. However, if the data entered in the object contains an error, the user is redirected to the new.html.erb page to resubmit the information and the errors are displayed.
Another example of such method pair is the edit and update methods. The edit method displays the table entry for an existing object, while the update method is invoked when the changes have been submitted.
</p>
<p>
<h1>Models of Cookbook Application</h1>
Model handles the data processing in a web application. Actions interact with the model to manipulate the data. Rails is capable of handling databases and this is facilitated by the model. You can base models on the Rails ActiveRecord module which contains support databases.
In our Cookbook application we have two models namely: Category and Recipe. They are represented by files category.rb and recipe.rb and each file is used to describe the relation between two classes. Let’s take a look at the two models
<br><b> category.rb</b>
<pre>
class Category < ActiveRecord::Base
has_many :recipes
end
</pre>

<b>recipe.rb</b>
<pre>class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>
</p>

*<b>Relationships in models</b>
<ul>one-to-one<br>
<pre>
class Syllabus < ActiveRecord::Base
belongs_to :course¬
end

class Course < ActiveRecord::Base
has_one :syllabus
end
</pre>
</ul>
<ul>many-many<br>
<pre>
class Student < ActiveRecord::Base
has_and_belongs_to_many :courses
end

class Course < ActiveRecord::Base
has_and_belongs_to_many :students
end
</pre></ul>

In Cookbook, we have many-one relationship between recipes and categories.
<p>
<h1>Views of Cookbook application</h1>
What is V in MVC? ‘V’ refers to views. Views are the actual interface that users can see. It is through views, that a user may request some data to be viewed or submits some data for processing.<br>
Views in rails are of the form file_name.html.erb. Here erb means embedded ruby. What html.erb denotes is some ruby code is embedded in HTML code. Like HTML, embedded ruby also uses tags to represent data. However, to distinguish it from the HTML code, ruby is embedded between <% %> if some non-assignment ruby operation is to be performed. If something needs to be displayed on screen, <%= %> is used.
Views are present in “app/views” folder in the rails application.
<br>
Name of the view files is same as the name of their respective controller. For e.g.:- if I have a controller movie with an action new, the corresponding view page will be new.html.erb in the app/views/movie directory.<br>
The Cookbook application views are as follows:

<b> Recipe Controller Views</b><br>
1. index.html.erb
<pre><nowiki><h1>Listing categories</h1>

<table>
<tr>
<th>Name</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @categories.each do |category| %>
<tr>
<td><%= category.name %></td>
<td><%= link_to 'Show', category %></td>
<td><%= link_to 'Edit', edit_category_path(category) %></td>
<td><%= link_to 'Destroy', category, method: :delete, data: { confirm: 'Are you sure?' } %></td>
</tr>
<% end %>
</table>
<br />

<%= link_to 'New Category', new_category_path %>
</nowiki></pre>

*<b><% @recipes.each do |recipe| %> </b>
Here @recipes is an instance variable of model recipe defined in index action of the controller ‘recipes’. It contains all the recipes currently present in our application. Then each recipe is taken from this instance variable and is assigned to the local variable recipe. All the subsequent lines display the recipe details (name, description and instruction).
<br>
*<b><%= link_to ‘Show’, recipe %> </b>
link_to is an ruby operator which is used to redirect the control to some other page. ‘Show’ is displayed as it is on the page and is an hyperlink. It links to a page pointed by recipe. The path is defined in the routes.rb file.
<br><br>
2. _form.html.erb
<br>
This is a partial. Partials are devices used for breaking the code in smaller, more manageable chunks. This helps in modularity and also maintain DRY principle[4]. With a partial, code for rendering a particular response is moved to its own file. So for e.g. we can use this same partial for creating and editing information, because the information involved is essentially the same.
<pre>
<%= form_for(@recipe) do |f| %>
<% if @recipe.errors.any? %>
<div id="error_explanation">
<h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>

<ul>
<% @recipe.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>

<div class="field">
<%= f.label :name %><br />
<%= f.text_field :name %>
</div>
<%= f.label :category %>
<%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %>
<div class="field">
<%= f.label :description %><br />
<%= f.text_field :description %>
</div>
<div class="field">
<%= f.label :instructions %><br />
<%= f.text_area :instructions %>
<%= f.submit %>
</div>
<% end %>
</pre>

* <b><%= form_for(@recipe) do |f| %></b>
This statement means to render a form for the instance variable @recipe.
If this page is being used for creating a new recipe, then the values for each key in the @recipe hash will be empty. If it is used for editing a recipe, @recipe will contain information corresponding to the recipe being edited.

*<b><% if @recipe.errors.any? %></b>
While saving an recipe or updating a recipe in the database, some violations may occur. Like the recipe name is left empty or its description is empty and so on. So while saving this information, database will signal some error. The errors are sent back to this page and are caught in @recipe.errors.any? statement.

*<b><%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %></b>
This statement creates a dropdown box.<br>
<ul>‘recipe’ : refers to the object to which the selected value is to be assigned. In this case , it is the recipe object</ul>
<ul>‘category_id’ : create a ‘category_id’ key in the recipe hash.</ul>
<ul>Category.all.collect {|c| [c[:name],c[:id]]} : recover all categories from the database and list them in the dropdown box. The value for each name is c[:id]. Whenever a category is selected by the user, its corresponding id is assigned to the ‘category_id’ key in the ‘recipe’ object.</ul>
<br>
3. new.html.erb<br>
This page is used to create a new recipe. This page simply renders the partial described above.
<pre>
<h1>New recipe</h1>
<%= render 'form' %>
<%= link_to 'Back', recipes_path %>
</pre>
*<b><%= render ‘form’ %> </b>
This statement renders the partial.
<br>
4. edit.html.erb
This page is used to edit a existing recipe. This page also renders the partial.
<pre>
<h1>Editing recipe</h1>
<%= render 'form' %>
<%= link_to 'Show', @recipe %> |
<%= link_to 'Back', recipes_path %>
</pre>
5. show.html.erb
This page is used to show a particular recipe requested by the user. The recipe requested is captured by the controller in the @recipe instance variable and is passed to this view.
<pre>
<p id="notice"><%= notice %></p>
<p>
<b>Name:</b>
<%= @recipe.name %>
</p>
<p>
<b>Description:</b>
<%= @recipe.description %>
</p>
<p>
<b>Instructions:</b>
<%= @recipe.instructions %>
</p>
<%= link_to 'Edit', edit_recipe_path(@recipe) %> |
<%= link_to 'Back', recipes_path %>
</pre>
<br>
<b>The Category Views are very similar to the recipe Views and can be created similarly.</b>

<h1>Conclusion</h1>

MVC was first proposed by Trygve Reenskaug in 1979. He broke applications into three types of components: models, which is responsible for maintaining the state of the application; views, which are responsible for generating a user interface; and controllers, which orchestrate the applications by receiving events from outside world, interact with model, and display an appropriate view to user. This separation of concerns led to far less computing, and in turn made the code easier to write and maintain.<br>
Use Ruby on Rails can implement MVC to build various types of web applications. The Cookbook is an easy starter. Readers can learn the basics of Ruby on Rails from this page.

<h1>References</h1>
*[1] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
*[2] http://en.wikipedia.org/wiki/Ruby_on_Rails
*[3] Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
*[4] http://en.wikipedia.org/wiki/Don't_repeat_yourself
*[5] http://guides.rubyonrails.org/getting_started.html
*[6] http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
*[7] http://en.wikipedia.org/wiki/Metaprogramming
*[8] http://net.tutsplus.com/tutorials/other/mvc-for-noobs/
*[9] Hotzner, S. (2007). Beginnning ruby on rail, Indianapolis: Wiley Publishing Inc
<br><br>

The old wiki can be found here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4d_ch.

CSC/ECE 517 Fall 2012/ch1b 1w38 nm

2012-10-04T01:56:32Z

Nmsarda:

<h1>Introduction</h1>
This page is aimed at asserting the importance of Model View Controller Architecture and how MVC is implemented in Cookbook application.

<h2>Model View Controller (MVC) Architecture</h2>

The purpose of creating MVC architecture is to have clear separation between the responsibilities of business logic and representation. In a nutshell the responsibilities are mentioned as below:

[[File:MVC.png|frame|none|MVC Responsibilities[8]]]

Model-View-Controller (MVC)[1] is an architectural pattern used in software engineering.In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface.<br>
The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. Having described the responsibilities of three components let’s take a look how these components interact with each other.

[[File:MVC_architecture.PNG|frame|none|MVC Architecture[9]]]

<h2>Ruby on Rails</h2>

Ruby on Rails[2] is an MVC framework. Rails enforces a structure for application, it helps to knit the models, views, and controllers as separate chunks of functionality while the program executes. No more external configuration needed. Rails is packed with features that make you more productive, with many of the following features building on one other.<br>
<b>Metaprogramming[7]:</b> Other frameworks use extensive code generation from scratch. Metaprogramming techniques use programs to write programs. Ruby is one of the best languages for metaprogramming, and Rails uses this capability well. Rails also uses code generation but relies much more on metaprogramming for the heavy lifting.<br>
<b>Active Record[6]:</b> Rails introduces the Active Record framework, which saves objects to the database. The Rails version of Active Record discovers the columns in a database schema and automatically attaches them to your domain objects using metaprogramming.<br>
<b>Convention over configuration:</b> Most web development frameworks for .NET or Java force you to write pages of configuration code. If you follow suggested naming conventions, Rails doesn't need much configuration.<br>
<b>Scaffolding:</b> You often create temporary code in the early stages of development to help get an application up quickly and see how major components work together. Rails automatically creates much of the scaffolding you'll need.<br>
<b>Built-in testing:</b> Rails creates simple automated tests which you can extend. Rails also provides supporting code called harnesses and fixtures that make test cases easier to write and run. Ruby can then execute all your automated tests with the rake utility.<br>
<b>Three environments:</b> Rails gives you three default environments: development, testing, and production. Each behaves slightly differently, making your entire software development cycle easier. For example, Rails creates a fresh copy of the Test database for each test run.

<h1>Cookbook Application</h1>
Cookbook Application is a very basic Ruby on Rails application. It is a great way to understand the nuances that ‘Ruby’ has to offer. It is built keeping in mind that the reader is new to the world of ruby and is developing his/her first Ruby on Rails application.
The motive of this wiki page is to make the reader understand how the Cookbook application was built. And on the way to building this application, user will be introduced to some key concepts like Model, Views and Controllers. At the end of this page, reader must fairly be ready to start building his/her basic Ruby on Rails application.

<h2>A simple application to start -- Cookbook application</h2>

Start a new project. While creating a new project, remember to select Rails Application option as follows

[[File:Start_application.png|frame|none|Start a new Application]]

When we create a Rails application, it automatically creates a bunch of files and folders as follows:

[[File:Listing_of_cookbook_application.png|frame|none|Listing_of_cookbook_application]]

We mainly use the app directory. This is where the heart of the application is stored i.e. Models, Views and controllers.

<h2>Using scaffold to create framework</h2>
Rails scaffolding is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job.<br>
In Rubymine, we can create a scaffold by right clicking on the current Project->New->Run Rails Generator ->scaffold. This will open a dialog box to create a scaffold where we can enter the name and the attributes along with their data type. Once the scaffold has been created RubyMine will generate the model, view and controller files respectively. These files do not contain any specific methods but they provide a framework which is useful for general applications. The user can modify the MVC behavior according to his/her application requirements. Each scaffold has create, read, update and delete methods declared in the controller class. A user can modify the behavior of the controller through these methods.
<br>

[[File:Create_Scaffold.png|frame|none|Creating a new scaffold]]<br><br>
[[File:Scaffold.png|frame|left|Scaffold]] [[File:New_Scaffold_Categories.png|frame|center|Creating scaffold for categories]]<br>

<h2>Working without scaffold</h2>

Or you don't want to create a fully standard framework with scaffold, then you can use RubyMine generate command to create model, controller and view individually. There are additional commands included in the generate command to create migration, assets, intergration_test and performance_test.

In the Cookbook application we are considering a Cookbook which contains recipes for various dishes. The recipes have been divided into different categories, for example there is a recipe for ice tea which belongs to the category of beverages. There is a relationship which is created between a recipe and a category which can be expressed as an ice tea belongs to beverages. We can have many such recipes belonging to a single category, in this case many to one relationship is established.

<h1>Controllers for Cookbook Application</h1>
The Cookbook application starts by entering a URL in the browser which sends the request to the web server. Since our web server supports Rails application, it will hand over the control to a Rails controller.
A controller ‘controls’ the entire application by responding to the incoming requests as needed. For example, consider the following URL http ://localhost:3000/categories/show which is decoded by the controller to know that its action named show has been invoked.
All the controllers inherit only the ApplicationController which in turn inherits the ActionController::Base class. ActionContoller module provides the basic support for the controllers in Rails.
In our Cookbook application we generate Categories controller using the scaffold mechanism which populates the controller with the basic methods such as index, create, show, new, edit, update and destroy.
A simple example of index method is as follows:
<pre>
def index
@categories = Category.all

respond_to do |format|
format.html # index.html.erb
format.json { render json: @categories }
end
end

</pre>
In ruby, @ operator is used to declare instance variables. The index method makes use of @categories instance variable which is populated with all the records in the Category table. The respond_to method is used for responding to particular type of request. It contains a block and a variable |format| which determines whether the incoming request should be responded with HTML (when we are interacting with a user) or JSON format (if we are returning an object).
After executing the code, the controller will render a template of the same name. (For this example, the template is views/categories/index.html.erb).
Similarly the show method is defined as follows:
<pre>
def show
@category = Category.find(params[:id])

respond_to do |format|
format.html # show.html.erb
format.json { render json: @category }
end
end

</pre>
The show method is used to display a particular object. The show method needs to access database to search for the given object. This is done using the find method which takes params[:id] as argument. The params[:id] contains the id or primary key of the object which is passed as a parameter to look up in the database and the result is stored in the instance variable. The result is displayed by rendering the show.html.erb file.<br><br>
<b>Active Record</b><br>
In ruby, a program deals with objects which are mapped into database relational databases. This kind of mapping is facilitated by the Active Record.<br>Active Record maps the Rails classes in to database tables and rails objects into database records.
This makes it easy to perform actions on database tables by invoking the class methods. Another benefit of Active Record is database migration. Migrations can manage the evolution of a schema used by several physical databases. It’s a solution to the common problem of adding a field to make a new feature work in your local database, but being unsure of how to push that change to other developers and to the production server. With migrations, you can describe the transformations in self-contained classes that can be checked into version control systems and executed against another database that might be one, two, or five versions behind.You can find a lot more details about rails migration here[8].
<p>
<b>Method Pairs</b>
<br>There are couple of method pairs such as new-create and edit-update which are executed in sequence. In method pair one method is responsible for display preparation and the other method validates the data and attempts it to save in the database.
<pre>
def new
@category = Category.new

respond_to do |format|
format.html # new.html.erb
format.json { render json: @category }
end

end
</pre>
<pre>
def create
@category = Category.new(params[:category])

respond_to do |format|
if @category.save
format.html { redirect_to @category, notice: 'Category was successfully created.' }
format.json { render json: @category, status: :created, location: @category }
else
format.html { render action: "new" }
format.json { render json: @category.errors, status: :unprocessable_entity }
end
end
end

</pre>

The new and create methods are known as method pairs which execute in sequence. The new method is used to instantiate a new Category object whereas create method is used to successfully save the object to the database. After execution of the new method, the controller renders the new.html.erb file which displays a form to create a new Category object. The user enters the required information in the form and the object id is returned in the URL on submitting the form. Consider the following URL is generated on submitting the form: http: //localhost:3000/categories/3.
This means that Category object with id =3 will be created. The details of the object will be processed by the create method.
The controller invokes the create method to store the object in the database. An observation can be made about the @category variable in the create method.
<pre>
@category = Category.new(params[:category])
</pre>
The parameters passed in the URL after creating a new object is stored in the params hash (denoted by params[]). In this case the params[] contains an object with category_id = 3. The params[] assigns the data of object with category_id =3 to the instance variable. The data entered in the instance variable is validated using the @category.save method. If no errors are found then the object stored in the database and a message on successful creation of the object is displayed to the user. However, if the data entered in the object contains an error, the user is redirected to the new.html.erb page to resubmit the information and the errors are displayed.
Another example of such method pair is the edit and update methods. The edit method displays the table entry for an existing object, while the update method is invoked when the changes have been submitted.
</p>
<p>
<h1>Models of Cookbook Application</h1>
Model handles the data processing in a web application. Actions interact with the model to manipulate the data. Rails is capable of handling databases and this is facilitated by the model. You can base models on the Rails ActiveRecord module which contains support databases.
In our Cookbook application we have two models namely: Category and Recipe. They are represented by files category.rb and recipe.rb and each file is used to describe the relation between two classes. Let’s take a look at the two models
<br><b> category.rb</b>
<pre>
class Category < ActiveRecord::Base
has_many :recipes
end
</pre>

<b>recipe.rb</b>
<pre>class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>
</p>

*<b>Relationships in models</b>
<ul>one-to-one<br>
<pre>
class Syllabus < ActiveRecord::Base
belongs_to :course¬
end

class Course < ActiveRecord::Base
has_one :syllabus
end
</pre>
</ul>
<ul>many-many<br>
<pre>
class Student < ActiveRecord::Base
has_and_belongs_to_many :courses
end

class Course < ActiveRecord::Base
has_and_belongs_to_many :students
end
</pre></ul>

In Cookbook, we have many-one relationship between recipes and categories.
<p>
<h1>Views of Cookbook application</h1>
What is V in MVC? ‘V’ refers to views. Views are the actual interface that users can see. It is through views, that a user may request some data to be viewed or submits some data for processing.<br>
Views in rails are of the form file_name.html.erb. Here erb means embedded ruby. What html.erb denotes is some ruby code is embedded in HTML code. Like HTML, embedded ruby also uses tags to represent data. However, to distinguish it from the HTML code, ruby is embedded between <% %> if some non-assignment ruby operation is to be performed. If something needs to be displayed on screen, <%= %> is used.
Views are present in “app/views” folder in the rails application.
<br>
Name of the view files is same as the name of their respective controller. For e.g.:- if I have a controller movie with an action new, the corresponding view page will be new.html.erb in the app/views/movie directory.<br>
The Cookbook application views are as follows:

<b> Recipe Controller Views</b><br>
1. index.html.erb
<pre><nowiki><h1>Listing categories</h1>

<table>
<tr>
<th>Name</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @categories.each do |category| %>
<tr>
<td><%= category.name %></td>
<td><%= link_to 'Show', category %></td>
<td><%= link_to 'Edit', edit_category_path(category) %></td>
<td><%= link_to 'Destroy', category, method: :delete, data: { confirm: 'Are you sure?' } %></td>
</tr>
<% end %>
</table>
<br />

<%= link_to 'New Category', new_category_path %>
</nowiki></pre>

*<b><% @recipes.each do |recipe| %> </b>
Here @recipes is an instance variable of model recipe defined in index action of the controller ‘recipes’. It contains all the recipes currently present in our application. Then each recipe is taken from this instance variable and is assigned to the local variable recipe. All the subsequent lines display the recipe details (name, description and instruction).
<br>
*<b><%= link_to ‘Show’, recipe %> </b>
link_to is an ruby operator which is used to redirect the control to some other page. ‘Show’ is displayed as it is on the page and is an hyperlink. It links to a page pointed by recipe. The path is defined in the routes.rb file.
<br><br>
2. _form.html.erb
<br>
This is a partial. Partials are devices used for breaking the code in smaller, more manageable chunks. This helps in modularity and also maintain DRY principle[4]. With a partial, code for rendering a particular response is moved to its own file. So for e.g. we can use this same partial for creating and editing information, because the information involved is essentially the same.
<pre>
<%= form_for(@recipe) do |f| %>
<% if @recipe.errors.any? %>
<div id="error_explanation">
<h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>

<ul>
<% @recipe.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>

<div class="field">
<%= f.label :name %><br />
<%= f.text_field :name %>
</div>
<%= f.label :category %>
<%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %>
<div class="field">
<%= f.label :description %><br />
<%= f.text_field :description %>
</div>
<div class="field">
<%= f.label :instructions %><br />
<%= f.text_area :instructions %>
<%= f.submit %>
</div>
<% end %>
</pre>

* <b><%= form_for(@recipe) do |f| %></b>
This statement means to render a form for the instance variable @recipe.
If this page is being used for creating a new recipe, then the values for each key in the @recipe hash will be empty. If it is used for editing a recipe, @recipe will contain information corresponding to the recipe being edited.

*<b><% if @recipe.errors.any? %></b>
While saving an recipe or updating a recipe in the database, some violations may occur. Like the recipe name is left empty or its description is empty and so on. So while saving this information, database will signal some error. The errors are sent back to this page and are caught in @recipe.errors.any? statement.

*<b><%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %></b>
This statement creates a dropdown box.<br>
<ul>‘recipe’ : refers to the object to which the selected value is to be assigned. In this case , it is the recipe object</ul>
<ul>‘category_id’ : create a ‘category_id’ key in the recipe hash.</ul>
<ul>Category.all.collect {|c| [c[:name],c[:id]]} : recover all categories from the database and list them in the dropdown box. The value for each name is c[:id]. Whenever a category is selected by the user, its corresponding id is assigned to the ‘category_id’ key in the ‘recipe’ object.</ul>
<br>
3. new.html.erb<br>
This page is used to create a new recipe. This page simply renders the partial described above.
<pre>
<h1>New recipe</h1>
<%= render 'form' %>
<%= link_to 'Back', recipes_path %>
</pre>
*<b><%= render ‘form’ %> </b>
This statement renders the partial.
<br>
4. edit.html.erb
This page is used to edit a existing recipe. This page also renders the partial.
<pre>
<h1>Editing recipe</h1>
<%= render 'form' %>
<%= link_to 'Show', @recipe %> |
<%= link_to 'Back', recipes_path %>
</pre>
5. show.html.erb
This page is used to show a particular recipe requested by the user. The recipe requested is captured by the controller in the @recipe instance variable and is passed to this view.
<pre>
<p id="notice"><%= notice %></p>
<p>
<b>Name:</b>
<%= @recipe.name %>
</p>
<p>
<b>Description:</b>
<%= @recipe.description %>
</p>
<p>
<b>Instructions:</b>
<%= @recipe.instructions %>
</p>
<%= link_to 'Edit', edit_recipe_path(@recipe) %> |
<%= link_to 'Back', recipes_path %>
</pre>
<br>
<b>The Category Views are very similar to the recipe Views and can be created similarly.</b>

<h1>Conclusion</h1>

MVC was first proposed by Trygve Reenskaug in 1979. He broke applications into three types of components: models, which is responsible for maintaining the state of the application; views, which are responsible for generating a user interface; and controllers, which orchestrate the applications by receiving events from outside world, interact with model, and display an appropriate view to user. This separation of concerns led to far less computing, and in turn made the code easier to write and maintain.<br>
Use Ruby on Rails can implement MVC to build various types of web applications. The Cookbook is an easy starter. Readers can learn the basics of Ruby on Rails from this page.

<h1>References</h1>
*[1] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
*[2] http://en.wikipedia.org/wiki/Ruby_on_Rails
*[3] Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
*[4] http://en.wikipedia.org/wiki/Don't_repeat_yourself
*[5] http://guides.rubyonrails.org/getting_started.html
*[6] http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
*[7] http://en.wikipedia.org/wiki/Metaprogramming
*[8] http://net.tutsplus.com/tutorials/other/mvc-for-noobs/
*[9] Hotzner, S. (2007). Beginnning ruby on rail, Indianapolis: Wiley Publishing Inc
<br><br>

The old wiki can be found here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4d_ch.

CSC/ECE 517 Fall 2012/ch1b 1w38 nm

2012-10-04T01:46:17Z

Nmsarda:

<h1>Introduction</h1>
This page is aimed at asserting the importance of Model View Controller Architecture and how MVC is implemented in Cookbook application.

<h2>Model View Controller (MVC) Architecture</h2>

The purpose of creating MVC architecture is to have clear separation between the responsibilities of business logic and representation. In a nutshell the responsibilities are mentioned as below:

[[File:MVC.png|frame|none|MVC Responsibilities[8]]]

Model-View-Controller (MVC)[1] is an architectural pattern used in software engineering.In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface.<br>
The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. Having described the responsibilities of three components let’s take a look how these components interact with each other.

[[File:MVC_architecture.PNG|frame|none|MVC Architecture[9]]]

<h2>Ruby on Rails</h2>

Ruby on Rails[2] is an MVC framework. Rails enforces a structure for application, it helps to knit the models, views, and controllers as separate chunks of functionality while the program executes. No more external configuration needed. Rails is packed with features that make you more productive, with many of the following features building on one other.<br>
<b>Metaprogramming[7]:</b> Other frameworks use extensive code generation from scratch. Metaprogramming techniques use programs to write programs. Ruby is one of the best languages for metaprogramming, and Rails uses this capability well. Rails also uses code generation but relies much more on metaprogramming for the heavy lifting.<br>
<b>Active Record[6]:</b> Rails introduces the Active Record framework, which saves objects to the database. The Rails version of Active Record discovers the columns in a database schema and automatically attaches them to your domain objects using metaprogramming.<br>
<b>Convention over configuration:</b> Most web development frameworks for .NET or Java force you to write pages of configuration code. If you follow suggested naming conventions, Rails doesn't need much configuration.<br>
<b>Scaffolding:</b> You often create temporary code in the early stages of development to help get an application up quickly and see how major components work together. Rails automatically creates much of the scaffolding you'll need.<br>
<b>Built-in testing:</b> Rails creates simple automated tests which you can extend. Rails also provides supporting code called harnesses and fixtures that make test cases easier to write and run. Ruby can then execute all your automated tests with the rake utility.<br>
<b>Three environments:</b> Rails gives you three default environments: development, testing, and production. Each behaves slightly differently, making your entire software development cycle easier. For example, Rails creates a fresh copy of the Test database for each test run.

<h1>Cookbook Application</h1>
Cookbook Application is a very basic Ruby on Rails application. It is a great way to understand the nuances that ‘Ruby’ has to offer. It is built keeping in mind that the reader is new to the world of ruby and is developing his/her first Ruby on Rails application.
The motive of this wiki page is to make the reader understand how the Cookbook application was built. And on the way to building this application, user will be introduced to some key concepts like Model, Views and Controllers. At the end of this page, reader must fairly be ready to start building his/her basic Ruby on Rails application.

<h2>A simple application to start -- Cookbook application</h2>

Start a new project. While creating a new project, remember to select Rails Application option as follows

[[File:Start_application.png|frame|none|Start a new Application]]

When we create a Rails application, rails automatically help us create a brunch of files and folders as follows:

[[File:Listing_of_cookbook_application.png|frame|none|Listing_of_cookbook_application]]

We mainly use the app directory. This is where the heart of the application is stored i.e. Models, Views and controllers.

<h2>Using scaffold to create framework</h2>
Rails scaffolding is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job.<br>
In Rubymine, we can create a scaffold by right clicking on the current Project->New->Run Rails Generator ->scaffold. This will open a dialog box to create a scaffold where we can enter the name and the attributes along with their data type. Once the scaffold has been created RubyMine will generate the model, view and controller files respectively. These files do not contain any specific methods but they provide a framework which is useful for general applications. The user can modify the MVC behavior according to his application requirements. Each scaffold has create, read, update and delete methods declared in the controller class. A user can modify the behavior of the controller through these methods.
<br>

[[File:Create_Scaffold.png|frame|none|Creating a new scaffold]]<br><br>
[[File:Scaffold.png|frame|left|Scaffold]] [[File:New_Scaffold_Categories.png|frame|center|Creating scaffold for categories]]<br>

<h2>Working without scaffold</h2>

Or you don't want to create a fully standard framework with scaffold, then you can use RubyMine generate command, you can create merely model, controller and view using generate command, there are many command included in the generate that you can use, expect those MVC, you can also crate migration, assets, intergration_test and performance_test. Or you don't want to create a empty controller and writing code all yourself you can also use scaffold_controller to create controller
Here is an example. You have create the Model and everything on your own without using the scaffolding in Ruby on Rails. You create the following class:

<pre>
class Dog < ActiveRecord::Base
end
</pre>
You can add a table Dogs. by
<pre>rails g migration CreateDogs</pre>
which also a generate command

In the Cookbook application we are considering a Cookbook which contains recipes for various dishes. The recipes have been divided into different categories, for example there is a recipe for ice tea which belongs to the category of beverages. There is a relationship which is created between a recipe and a category which can be expressed as an ice tea belongs to beverages. We can have many such recipes belonging to a single category, in this case many to one relationship is established.

<h1>Controllers for Cookbook Application</h1>
The Cookbook application starts by entering a URL in the browser which sends the request to the web server. Since our web server supports Rails application, it will hand over the control to a Rails controller.
A controller ‘controls’ the entire application by responding to the incoming requests as needed. For example, consider the following URL http ://localhost:3000/categories/show which is decoded by the controller to know that its action named show has been invoked.
All the controllers inherit only the ApplicationController which in turn inherits the ActionController::Base class. ActionContoller module provides the basic support for the controllers in Rails.
In our Cookbook application we generate Categories controller using the scaffold mechanism which populates the controller with the basic methods such as index, create, show, new, edit, update and destroy.
A simple example of index method is as follows:
<pre>
def index
@categories = Category.all

respond_to do |format|
format.html # index.html.erb
format.json { render json: @categories }
end
end

</pre>
In ruby, @ operator is used to declare instance variables. The index method makes use of @categories instance variable which is populated with all the records in the Category table. The respond_to method is used for responding to particular type of request. It contains a block and a variable |format| which determines whether the incoming request should be responded with HTML (when we are interacting with a user) or JSON format (if we are returning an object).
After executing the code, the controller will render a template of the same name. (For this example, the template is views/categories/index.html.erb).
Similarly the show method is defined as follows:
<pre>
def show
@category = Category.find(params[:id])

respond_to do |format|
format.html # show.html.erb
format.json { render json: @category }
end
end

</pre>
The show method is used to display a particular object. The show method needs to access database to search for the given object. This is done using the find method which takes params[:id] as argument. The params[:id] contains the id or primary key of the object which is passed as a parameter to look up in the database and the result is stored in the instance variable. The result is displayed by rendering the show.html.erb file.<br><br>
<b>Active Record</b><br>
In ruby, a program deals with objects which are mapped into database relational databases. This kind of mapping is facilitated by the Active Record.<br>Active Record maps the Rails classes in to database tables and rails objects into database records.
This makes it easy to perform actions on database tables by invoking the class methods. Another benefit of Active Record is database migration. Migrations can manage the evolution of a schema used by several physical databases. It’s a solution to the common problem of adding a field to make a new feature work in your local database, but being unsure of how to push that change to other developers and to the production server. With migrations, you can describe the transformations in self-contained classes that can be checked into version control systems and executed against another database that might be one, two, or five versions behind.You can find a lot more details about rails migration here[8].
<p>
<b>Method Pairs</b>
<br>There are couple of method pairs such as new-create and edit-update which are executed in sequence. In method pair one method is responsible for display preparation and the other method validates the data and attempts it to save in the database.
<pre>
def new
@category = Category.new

respond_to do |format|
format.html # new.html.erb
format.json { render json: @category }
end

end
</pre>
<pre>
def create
@category = Category.new(params[:category])

respond_to do |format|
if @category.save
format.html { redirect_to @category, notice: 'Category was successfully created.' }
format.json { render json: @category, status: :created, location: @category }
else
format.html { render action: "new" }
format.json { render json: @category.errors, status: :unprocessable_entity }
end
end
end

</pre>

The new and create methods are known as method pairs which execute in sequence. The new method is used to instantiate a new Category object whereas create method is used to successfully save the object to the database. After execution of the new method, the controller renders the new.html.erb file which displays a form to create a new Category object. The user enters the required information in the form and the object id is returned in the URL on submitting the form. Consider the following URL is generated on submitting the form: http: //localhost:3000/categories/3.
This means that Category object with id =3 will be created. The details of the object will be processed by the create method.
The controller invokes the create method to store the object in the database. An observation can be made about the @category variable in the create method.
<pre>
@category = Category.new(params[:category])
</pre>
The parameters passed in the URL after creating a new object is stored in the params hash (denoted by params[]). In this case the params[] contains an object with category_id = 3. The params[] assigns the data of object with category_id =3 to the instance variable. The data entered in the instance variable is validated using the @category.save method. If no errors are found then the object stored in the database and a message on successful creation of the object is displayed to the user. However, if the data entered in the object contains an error, the user is redirected to the new.html.erb page to resubmit the information and the errors are displayed.
Another example of such method pair is the edit and update methods. The edit method displays the table entry for an existing object, while the update method is invoked when the changes have been submitted.
</p>
<p>
<h1>Models of Cookbook Application</h1>
Model handles the data processing in a web application. Actions interact with the model to manipulate the data. Rails is capable of handling databases and this is facilitated by the model. You can base models on the Rails ActiveRecord module which contains support databases.
In our Cookbook application we have two models namely: Category and Recipe. They are represented by files category.rb and recipe.rb and each file is used to describe the relation between two classes. Let’s take a look at the two models
<br><b> category.rb</b>
<pre>
class Category < ActiveRecord::Base
has_many :recipes
end
</pre>

<b>recipe.rb</b>
<pre>class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>
</p>

*<b>Relationships in models</b>
<ul>one-to-one<br>
<pre>
class Syllabus < ActiveRecord::Base
belongs_to :course¬
end

class Course < ActiveRecord::Base
has_one :syllabus
end
</pre>
</ul>
<ul>many-many<br>
<pre>
class Student < ActiveRecord::Base
has_and_belongs_to_many :courses
end

class Course < ActiveRecord::Base
has_and_belongs_to_many :students
end
</pre></ul>

In Cookbook, we have many-one relationship between recipes and categories.
<p>
<h1>Views of Cookbook application</h1>
What is V in MVC? ‘V’ refers to views. Views are the actual interface that users can see. It is through views, that a user may request some data to be viewed or submits some data for processing.<br>
Views in rails are of the form file_name.html.erb. Here erb means embedded ruby. What html.erb denotes is some ruby code is embedded in HTML code. Like HTML, embedded ruby also uses tags to represent data. However, to distinguish it from the HTML code, ruby is embedded between <% %> if some non-assignment ruby operation is to be performed. If something needs to be displayed on screen, <%= %> is used.
Views are present in “app/views” folder in the rails application.
<br>
Name of the view files is same as the name of their respective controller. For e.g.:- if I have a controller movie with an action new, the corresponding view page will be new.html.erb in the app/views/movie directory.<br>
The Cookbook application views are as follows:

<b> Recipe Controller Views</b><br>
1. index.html.erb
<pre><nowiki><h1>Listing categories</h1>

<table>
<tr>
<th>Name</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @categories.each do |category| %>
<tr>
<td><%= category.name %></td>
<td><%= link_to 'Show', category %></td>
<td><%= link_to 'Edit', edit_category_path(category) %></td>
<td><%= link_to 'Destroy', category, method: :delete, data: { confirm: 'Are you sure?' } %></td>
</tr>
<% end %>
</table>
<br />

<%= link_to 'New Category', new_category_path %>
</nowiki></pre>

*<b><% @recipes.each do |recipe| %> </b>
Here @recipes is an instance variable of model recipe defined in index action of the controller ‘recipes’. It contains all the recipes currently present in our application. Then each recipe is taken from this instance variable and is assigned to the local variable recipe. All the subsequent lines display the recipe details (name, description and instruction).
<br>
*<b><%= link_to ‘Show’, recipe %> </b>
link_to is an ruby operator which is used to redirect the control to some other page. ‘Show’ is displayed as it is on the page and is an hyperlink. It links to a page pointed by recipe. The path is defined in the routes.rb file.
<br><br>
2. _form.html.erb
<br>
This is a partial. Partials are devices used for breaking the code in smaller, more manageable chunks. This helps in modularity and also maintain DRY principle[4]. With a partial, code for rendering a particular response is moved to its own file. So for e.g. we can use this same partial for creating and editing information, because the information involved is essentially the same.
<pre>
<%= form_for(@recipe) do |f| %>
<% if @recipe.errors.any? %>
<div id="error_explanation">
<h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>

<ul>
<% @recipe.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>

<div class="field">
<%= f.label :name %><br />
<%= f.text_field :name %>
</div>
<%= f.label :category %>
<%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %>
<div class="field">
<%= f.label :description %><br />
<%= f.text_field :description %>
</div>
<div class="field">
<%= f.label :instructions %><br />
<%= f.text_area :instructions %>
<%= f.submit %>
</div>
<% end %>
</pre>

* <b><%= form_for(@recipe) do |f| %></b>
This statement means to render a form for the instance variable @recipe.
If this page is being used for creating a new recipe, then the values for each key in the @recipe hash will be empty. If it is used for editing a recipe, @recipe will contain information corresponding to the recipe being edited.

*<b><% if @recipe.errors.any? %></b>
While saving an recipe or updating a recipe in the database, some violations may occur. Like the recipe name is left empty or its description is empty and so on. So while saving this information, database will signal some error. The errors are sent back to this page and are caught in @recipe.errors.any? statement.

*<b><%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %></b>
This statement creates a dropdown box.<br>
<ul>‘recipe’ : refers to the object to which the selected value is to be assigned. In this case , it is the recipe object</ul>
<ul>‘category_id’ : create a ‘category_id’ key in the recipe hash.</ul>
<ul>Category.all.collect {|c| [c[:name],c[:id]]} : recover all categories from the database and list them in the dropdown box. The value for each name is c[:id]. Whenever a category is selected by the user, its corresponding id is assigned to the ‘category_id’ key in the ‘recipe’ object.</ul>
<br>
3. new.html.erb<br>
This page is used to create a new recipe. This page simply renders the partial described above.
<pre>
<h1>New recipe</h1>
<%= render 'form' %>
<%= link_to 'Back', recipes_path %>
</pre>
*<b><%= render ‘form’ %> </b>
This statement renders the partial.
<br>
4. edit.html.erb
This page is used to edit a existing recipe. This page also renders the partial.
<pre>
<h1>Editing recipe</h1>
<%= render 'form' %>
<%= link_to 'Show', @recipe %> |
<%= link_to 'Back', recipes_path %>
</pre>
5. show.html.erb
This page is used to show a particular recipe requested by the user. The recipe requested is captured by the controller in the @recipe instance variable and is passed to this view.
<pre>
<p id="notice"><%= notice %></p>
<p>
<b>Name:</b>
<%= @recipe.name %>
</p>
<p>
<b>Description:</b>
<%= @recipe.description %>
</p>
<p>
<b>Instructions:</b>
<%= @recipe.instructions %>
</p>
<%= link_to 'Edit', edit_recipe_path(@recipe) %> |
<%= link_to 'Back', recipes_path %>
</pre>
<br>
<b>The Category Views are very similar to the recipe Views and can be created similarly.</b>

<h1>Conclusion</h1>

MVC was first proposed by Trygve Reenskaug in 1979. He broke applications into three types of components: models, which is responsible for maintaining the state of the application; views, which are responsible for generating a user interface; and controllers, which orchestrate the applications by receiving events from outside world, interact with model, and display an appropriate view to user. This separation of concerns led to far less computing, and in turn made the code easier to write and maintain.<br>
Use Ruby on Rails can implement MVC to build various types of web applications. The Cookbook is an easy starter. Readers can learn the basics of Ruby on Rails from this page.

<h1>References</h1>
*[1] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
*[2] http://en.wikipedia.org/wiki/Ruby_on_Rails
*[3] Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
*[4] http://en.wikipedia.org/wiki/Don't_repeat_yourself
*[5] http://guides.rubyonrails.org/getting_started.html
*[6] http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
*[7] http://en.wikipedia.org/wiki/Metaprogramming
*[8] http://net.tutsplus.com/tutorials/other/mvc-for-noobs/
*[9] Hotzner, S. (2007). Beginnning ruby on rail, Indianapolis: Wiley Publishing Inc
<br><br>

The old wiki can be found here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4d_ch.

CSC/ECE 517 Fall 2012/ch1b 1w38 nm

2012-10-04T01:45:24Z

Nmsarda:

<h1>Introduction</h1>
This page is aimed at asserting the importance of Model View Controller Architecture and how MVC is implemented in Cookbook application.

<h2>Model View Controller (MVC) Architecture</h2>

The purpose of creating MVC architecture is to have clear separation between the responsibilities of business logic and representation. In a nutshell the responsibilities are mentioned as below:

[[File:MVC.png|frame|none|MVC Responsibilities[8]]]

Model-View-Controller (MVC)[1] is an architectural pattern used in software engineering.In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface.<br>
The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. Having described the responsibilities of three components let’s take a look how these components interact with each other.

[[File:MVC_architecture.PNG|frame|none|MVC Architecture[9]]]

<h2>Ruby on Rails</h2>

Ruby on Rails[2] is an MVC framework. Rails enforces a structure for application, it helps to knit the models, views, and controllers as separate chunks of functionality while the program executes. No more external configuration needed. Rails is packed with features that make you more productive, with many of the following features building on one other.<br>
<b>Metaprogramming[7]:</b> Other frameworks use extensive code generation from scratch. Metaprogramming techniques use programs to write programs. Ruby is one of the best languages for metaprogramming, and Rails uses this capability well. Rails also uses code generation but relies much more on metaprogramming for the heavy lifting.<br>
<b>Active Record[6]:</b> Rails introduces the Active Record framework, which saves objects to the database. The Rails version of Active Record discovers the columns in a database schema and automatically attaches them to your domain objects using metaprogramming.<br>
<b>Convention over configuration:</b> Most web development frameworks for .NET or Java force you to write pages of configuration code. If you follow suggested naming conventions, Rails doesn't need much configuration.<br>
<b>Scaffolding:</b> You often create temporary code in the early stages of development to help get an application up quickly and see how major components work together. Rails automatically creates much of the scaffolding you'll need.<br>
<b>Built-in testing:</b> Rails creates simple automated tests you can then extend. Rails also provides supporting code called harnesses and fixtures that make test cases easier to write and run. Ruby can then execute all your automated tests with the rake utility.<br>
<b>Three environments:</b> Rails gives you three default environments: development, testing, and production. Each behaves slightly differently, making your entire software development cycle easier. For example, Rails creates a fresh copy of the Test database for each test run.

<h1>Cookbook Application</h1>
Cookbook Application is a very basic Ruby on Rails application. It is a great way to understand the nuances that ‘Ruby’ has to offer. It is built keeping in mind that the reader is new to the world of ruby and is developing his/her first Ruby on Rails application.
The motive of this wiki page is to make the reader understand how the Cookbook application was built. And on the way to building this application, user will be introduced to some key concepts like Model, Views and Controllers. At the end of this page, reader must fairly be ready to start building his/her basic Ruby on Rails application.

<h2>A simple application to start -- Cookbook application</h2>

Start a new project. While creating a new project, remember to select Rails Application option as follows

[[File:Start_application.png|frame|none|Start a new Application]]

When we create a Rails application, rails automatically help us create a brunch of files and folders as follows:

[[File:Listing_of_cookbook_application.png|frame|none|Listing_of_cookbook_application]]

We mainly use the app directory. This is where the heart of the application is stored i.e. Models, Views and controllers.

<h2>Using scaffold to create framework</h2>
Rails scaffolding is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job.<br>
In Rubymine, we can create a scaffold by right clicking on the current Project->New->Run Rails Generator ->scaffold. This will open a dialog box to create a scaffold where we can enter the name and the attributes along with their data type. Once the scaffold has been created RubyMine will generate the model, view and controller files respectively. These files do not contain any specific methods but they provide a framework which is useful for general applications. The user can modify the MVC behavior according to his application requirements. Each scaffold has create, read, update and delete methods declared in the controller class. A user can modify the behavior of the controller through these methods.
<br>

[[File:Create_Scaffold.png|frame|none|Creating a new scaffold]]<br><br>
[[File:Scaffold.png|frame|left|Scaffold]] [[File:New_Scaffold_Categories.png|frame|center|Creating scaffold for categories]]<br>

<h2>Working without scaffold</h2>

Or you don't want to create a fully standard framework with scaffold, then you can use RubyMine generate command, you can create merely model, controller and view using generate command, there are many command included in the generate that you can use, expect those MVC, you can also crate migration, assets, intergration_test and performance_test. Or you don't want to create a empty controller and writing code all yourself you can also use scaffold_controller to create controller
Here is an example. You have create the Model and everything on your own without using the scaffolding in Ruby on Rails. You create the following class:

<pre>
class Dog < ActiveRecord::Base
end
</pre>
You can add a table Dogs. by
<pre>rails g migration CreateDogs</pre>
which also a generate command

In the Cookbook application we are considering a Cookbook which contains recipes for various dishes. The recipes have been divided into different categories, for example there is a recipe for ice tea which belongs to the category of beverages. There is a relationship which is created between a recipe and a category which can be expressed as an ice tea belongs to beverages. We can have many such recipes belonging to a single category, in this case many to one relationship is established.

<h1>Controllers for Cookbook Application</h1>
The Cookbook application starts by entering a URL in the browser which sends the request to the web server. Since our web server supports Rails application, it will hand over the control to a Rails controller.
A controller ‘controls’ the entire application by responding to the incoming requests as needed. For example, consider the following URL http ://localhost:3000/categories/show which is decoded by the controller to know that its action named show has been invoked.
All the controllers inherit only the ApplicationController which in turn inherits the ActionController::Base class. ActionContoller module provides the basic support for the controllers in Rails.
In our Cookbook application we generate Categories controller using the scaffold mechanism which populates the controller with the basic methods such as index, create, show, new, edit, update and destroy.
A simple example of index method is as follows:
<pre>
def index
@categories = Category.all

respond_to do |format|
format.html # index.html.erb
format.json { render json: @categories }
end
end

</pre>
In ruby, @ operator is used to declare instance variables. The index method makes use of @categories instance variable which is populated with all the records in the Category table. The respond_to method is used for responding to particular type of request. It contains a block and a variable |format| which determines whether the incoming request should be responded with HTML (when we are interacting with a user) or JSON format (if we are returning an object).
After executing the code, the controller will render a template of the same name. (For this example, the template is views/categories/index.html.erb).
Similarly the show method is defined as follows:
<pre>
def show
@category = Category.find(params[:id])

respond_to do |format|
format.html # show.html.erb
format.json { render json: @category }
end
end

</pre>
The show method is used to display a particular object. The show method needs to access database to search for the given object. This is done using the find method which takes params[:id] as argument. The params[:id] contains the id or primary key of the object which is passed as a parameter to look up in the database and the result is stored in the instance variable. The result is displayed by rendering the show.html.erb file.<br><br>
<b>Active Record</b><br>
In ruby, a program deals with objects which are mapped into database relational databases. This kind of mapping is facilitated by the Active Record.<br>Active Record maps the Rails classes in to database tables and rails objects into database records.
This makes it easy to perform actions on database tables by invoking the class methods. Another benefit of Active Record is database migration. Migrations can manage the evolution of a schema used by several physical databases. It’s a solution to the common problem of adding a field to make a new feature work in your local database, but being unsure of how to push that change to other developers and to the production server. With migrations, you can describe the transformations in self-contained classes that can be checked into version control systems and executed against another database that might be one, two, or five versions behind.You can find a lot more details about rails migration here[8].
<p>
<b>Method Pairs</b>
<br>There are couple of method pairs such as new-create and edit-update which are executed in sequence. In method pair one method is responsible for display preparation and the other method validates the data and attempts it to save in the database.
<pre>
def new
@category = Category.new

respond_to do |format|
format.html # new.html.erb
format.json { render json: @category }
end

end
</pre>
<pre>
def create
@category = Category.new(params[:category])

respond_to do |format|
if @category.save
format.html { redirect_to @category, notice: 'Category was successfully created.' }
format.json { render json: @category, status: :created, location: @category }
else
format.html { render action: "new" }
format.json { render json: @category.errors, status: :unprocessable_entity }
end
end
end

</pre>

The new and create methods are known as method pairs which execute in sequence. The new method is used to instantiate a new Category object whereas create method is used to successfully save the object to the database. After execution of the new method, the controller renders the new.html.erb file which displays a form to create a new Category object. The user enters the required information in the form and the object id is returned in the URL on submitting the form. Consider the following URL is generated on submitting the form: http: //localhost:3000/categories/3.
This means that Category object with id =3 will be created. The details of the object will be processed by the create method.
The controller invokes the create method to store the object in the database. An observation can be made about the @category variable in the create method.
<pre>
@category = Category.new(params[:category])
</pre>
The parameters passed in the URL after creating a new object is stored in the params hash (denoted by params[]). In this case the params[] contains an object with category_id = 3. The params[] assigns the data of object with category_id =3 to the instance variable. The data entered in the instance variable is validated using the @category.save method. If no errors are found then the object stored in the database and a message on successful creation of the object is displayed to the user. However, if the data entered in the object contains an error, the user is redirected to the new.html.erb page to resubmit the information and the errors are displayed.
Another example of such method pair is the edit and update methods. The edit method displays the table entry for an existing object, while the update method is invoked when the changes have been submitted.
</p>
<p>
<h1>Models of Cookbook Application</h1>
Model handles the data processing in a web application. Actions interact with the model to manipulate the data. Rails is capable of handling databases and this is facilitated by the model. You can base models on the Rails ActiveRecord module which contains support databases.
In our Cookbook application we have two models namely: Category and Recipe. They are represented by files category.rb and recipe.rb and each file is used to describe the relation between two classes. Let’s take a look at the two models
<br><b> category.rb</b>
<pre>
class Category < ActiveRecord::Base
has_many :recipes
end
</pre>

<b>recipe.rb</b>
<pre>class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>
</p>

*<b>Relationships in models</b>
<ul>one-to-one<br>
<pre>
class Syllabus < ActiveRecord::Base
belongs_to :course¬
end

class Course < ActiveRecord::Base
has_one :syllabus
end
</pre>
</ul>
<ul>many-many<br>
<pre>
class Student < ActiveRecord::Base
has_and_belongs_to_many :courses
end

class Course < ActiveRecord::Base
has_and_belongs_to_many :students
end
</pre></ul>

In Cookbook, we have many-one relationship between recipes and categories.
<p>
<h1>Views of Cookbook application</h1>
What is V in MVC? ‘V’ refers to views. Views are the actual interface that users can see. It is through views, that a user may request some data to be viewed or submits some data for processing.<br>
Views in rails are of the form file_name.html.erb. Here erb means embedded ruby. What html.erb denotes is some ruby code is embedded in HTML code. Like HTML, embedded ruby also uses tags to represent data. However, to distinguish it from the HTML code, ruby is embedded between <% %> if some non-assignment ruby operation is to be performed. If something needs to be displayed on screen, <%= %> is used.
Views are present in “app/views” folder in the rails application.
<br>
Name of the view files is same as the name of their respective controller. For e.g.:- if I have a controller movie with an action new, the corresponding view page will be new.html.erb in the app/views/movie directory.<br>
The Cookbook application views are as follows:

<b> Recipe Controller Views</b><br>
1. index.html.erb
<pre><nowiki><h1>Listing categories</h1>

<table>
<tr>
<th>Name</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @categories.each do |category| %>
<tr>
<td><%= category.name %></td>
<td><%= link_to 'Show', category %></td>
<td><%= link_to 'Edit', edit_category_path(category) %></td>
<td><%= link_to 'Destroy', category, method: :delete, data: { confirm: 'Are you sure?' } %></td>
</tr>
<% end %>
</table>
<br />

<%= link_to 'New Category', new_category_path %>
</nowiki></pre>

*<b><% @recipes.each do |recipe| %> </b>
Here @recipes is an instance variable of model recipe defined in index action of the controller ‘recipes’. It contains all the recipes currently present in our application. Then each recipe is taken from this instance variable and is assigned to the local variable recipe. All the subsequent lines display the recipe details (name, description and instruction).
<br>
*<b><%= link_to ‘Show’, recipe %> </b>
link_to is an ruby operator which is used to redirect the control to some other page. ‘Show’ is displayed as it is on the page and is an hyperlink. It links to a page pointed by recipe. The path is defined in the routes.rb file.
<br><br>
2. _form.html.erb
<br>
This is a partial. Partials are devices used for breaking the code in smaller, more manageable chunks. This helps in modularity and also maintain DRY principle[4]. With a partial, code for rendering a particular response is moved to its own file. So for e.g. we can use this same partial for creating and editing information, because the information involved is essentially the same.
<pre>
<%= form_for(@recipe) do |f| %>
<% if @recipe.errors.any? %>
<div id="error_explanation">
<h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>

<ul>
<% @recipe.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>

<div class="field">
<%= f.label :name %><br />
<%= f.text_field :name %>
</div>
<%= f.label :category %>
<%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %>
<div class="field">
<%= f.label :description %><br />
<%= f.text_field :description %>
</div>
<div class="field">
<%= f.label :instructions %><br />
<%= f.text_area :instructions %>
<%= f.submit %>
</div>
<% end %>
</pre>

* <b><%= form_for(@recipe) do |f| %></b>
This statement means to render a form for the instance variable @recipe.
If this page is being used for creating a new recipe, then the values for each key in the @recipe hash will be empty. If it is used for editing a recipe, @recipe will contain information corresponding to the recipe being edited.

*<b><% if @recipe.errors.any? %></b>
While saving an recipe or updating a recipe in the database, some violations may occur. Like the recipe name is left empty or its description is empty and so on. So while saving this information, database will signal some error. The errors are sent back to this page and are caught in @recipe.errors.any? statement.

*<b><%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %></b>
This statement creates a dropdown box.<br>
<ul>‘recipe’ : refers to the object to which the selected value is to be assigned. In this case , it is the recipe object</ul>
<ul>‘category_id’ : create a ‘category_id’ key in the recipe hash.</ul>
<ul>Category.all.collect {|c| [c[:name],c[:id]]} : recover all categories from the database and list them in the dropdown box. The value for each name is c[:id]. Whenever a category is selected by the user, its corresponding id is assigned to the ‘category_id’ key in the ‘recipe’ object.</ul>
<br>
3. new.html.erb<br>
This page is used to create a new recipe. This page simply renders the partial described above.
<pre>
<h1>New recipe</h1>
<%= render 'form' %>
<%= link_to 'Back', recipes_path %>
</pre>
*<b><%= render ‘form’ %> </b>
This statement renders the partial.
<br>
4. edit.html.erb
This page is used to edit a existing recipe. This page also renders the partial.
<pre>
<h1>Editing recipe</h1>
<%= render 'form' %>
<%= link_to 'Show', @recipe %> |
<%= link_to 'Back', recipes_path %>
</pre>
5. show.html.erb
This page is used to show a particular recipe requested by the user. The recipe requested is captured by the controller in the @recipe instance variable and is passed to this view.
<pre>
<p id="notice"><%= notice %></p>
<p>
<b>Name:</b>
<%= @recipe.name %>
</p>
<p>
<b>Description:</b>
<%= @recipe.description %>
</p>
<p>
<b>Instructions:</b>
<%= @recipe.instructions %>
</p>
<%= link_to 'Edit', edit_recipe_path(@recipe) %> |
<%= link_to 'Back', recipes_path %>
</pre>
<br>
<b>The Category Views are very similar to the recipe Views and can be created similarly.</b>

<h1>Conclusion</h1>

MVC was first proposed by Trygve Reenskaug in 1979. He broke applications into three types of components: models, which is responsible for maintaining the state of the application; views, which are responsible for generating a user interface; and controllers, which orchestrate the applications by receiving events from outside world, interact with model, and display an appropriate view to user. This separation of concerns led to far less computing, and in turn made the code easier to write and maintain.<br>
Use Ruby on Rails can implement MVC to build various types of web applications. The Cookbook is an easy starter. Readers can learn the basics of Ruby on Rails from this page.

<h1>References</h1>
*[1] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
*[2] http://en.wikipedia.org/wiki/Ruby_on_Rails
*[3] Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
*[4] http://en.wikipedia.org/wiki/Don't_repeat_yourself
*[5] http://guides.rubyonrails.org/getting_started.html
*[6] http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
*[7] http://en.wikipedia.org/wiki/Metaprogramming
*[8] http://net.tutsplus.com/tutorials/other/mvc-for-noobs/
*[9] Hotzner, S. (2007). Beginnning ruby on rail, Indianapolis: Wiley Publishing Inc
<br><br>

The old wiki can be found here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4d_ch.

CSC/ECE 517 Fall 2012/ch1b 1w38 nm

2012-10-04T01:44:38Z

Nmsarda:

<h1>Introduction</h1>
This page is aimed at asserting the importance of Model View Controller Architecture and how MVC is implemented in Cookbook application.

<h2>Model View Controller (MVC) Architecture</h2>

The purpose of creating MVC architecture is to have clear separation between the responsibilities of business logic and representation. In a nutshell the responsibilities are mentioned as below:

[[File:MVC.png|frame|none|MVC Responsibilities[8]]]

Model-View-Controller (MVC)[1] is an architectural pattern used in software engineering.In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface.<br>
The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. Having described the responsibilities of three components let’s take a look how these components interact with each other.

[[File:MVC_architecture.PNG|frame|none|MVC Architecture[9]]]

<h2>Ruby on Rails</h2>

Ruby on Rails[2] is an MVC framework. Rails enforces a structure for application, it helps to knit the models, views, and controllers as separate chunks of functionality while the program executes. No more external configuration needed. Rails is packed with features that make you more productive, with many of the following features building on one other.<br>
<b>Metaprogramming[7]:</b> Other frameworks use extensive code generation from scratch. Metaprogramming[9] techniques use programs to write programs. Ruby is one of the best languages for metaprogramming, and Rails uses this capability well. Rails also uses code generation but relies much more on metaprogramming for the heavy lifting.<br>
<b>Active Record:</b> Rails introduces the Active Record[6] framework, which saves objects to the database. The Rails version of Active Record discovers the columns in a database schema and automatically attaches them to your domain objects using metaprogramming.<br>
<b>Convention over configuration:</b> Most web development frameworks for .NET or Java force you to write pages of configuration code. If you follow suggested naming conventions, Rails doesn't need much configuration.<br>
<b>Scaffolding:</b> You often create temporary code in the early stages of development to help get an application up quickly and see how major components work together. Rails automatically creates much of the scaffolding you'll need.<br>
<b>Built-in testing:</b> Rails creates simple automated tests you can then extend. Rails also provides supporting code called harnesses and fixtures that make test cases easier to write and run. Ruby can then execute all your automated tests with the rake utility.<br>
<b>Three environments:</b> Rails gives you three default environments: development, testing, and production. Each behaves slightly differently, making your entire software development cycle easier. For example, Rails creates a fresh copy of the Test database for each test run.

<h1>Cookbook Application</h1>
Cookbook Application is a very basic Ruby on Rails application. It is a great way to understand the nuances that ‘Ruby’ has to offer. It is built keeping in mind that the reader is new to the world of ruby and is developing his/her first Ruby on Rails application.
The motive of this wiki page is to make the reader understand how the Cookbook application was built. And on the way to building this application, user will be introduced to some key concepts like Model, Views and Controllers. At the end of this page, reader must fairly be ready to start building his/her basic Ruby on Rails application.

<h2>A simple application to start -- Cookbook application</h2>

Start a new project. While creating a new project, remember to select Rails Application option as follows

[[File:Start_application.png|frame|none|Start a new Application]]

When we create a Rails application, rails automatically help us create a brunch of files and folders as follows:

[[File:Listing_of_cookbook_application.png|frame|none|Listing_of_cookbook_application]]

We mainly use the app directory. This is where the heart of the application is stored i.e. Models, Views and controllers.

<h2>Using scaffold to create framework</h2>
Rails scaffolding is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job.<br>
In Rubymine, we can create a scaffold by right clicking on the current Project->New->Run Rails Generator ->scaffold. This will open a dialog box to create a scaffold where we can enter the name and the attributes along with their data type. Once the scaffold has been created RubyMine will generate the model, view and controller files respectively. These files do not contain any specific methods but they provide a framework which is useful for general applications. The user can modify the MVC behavior according to his application requirements. Each scaffold has create, read, update and delete methods declared in the controller class. A user can modify the behavior of the controller through these methods.
<br>

[[File:Create_Scaffold.png|frame|none|Creating a new scaffold]]<br><br>
[[File:Scaffold.png|frame|left|Scaffold]] [[File:New_Scaffold_Categories.png|frame|center|Creating scaffold for categories]]<br>

<h2>Working without scaffold</h2>

Or you don't want to create a fully standard framework with scaffold, then you can use RubyMine generate command, you can create merely model, controller and view using generate command, there are many command included in the generate that you can use, expect those MVC, you can also crate migration, assets, intergration_test and performance_test. Or you don't want to create a empty controller and writing code all yourself you can also use scaffold_controller to create controller
Here is an example. You have create the Model and everything on your own without using the scaffolding in Ruby on Rails. You create the following class:

<pre>
class Dog < ActiveRecord::Base
end
</pre>
You can add a table Dogs. by
<pre>rails g migration CreateDogs</pre>
which also a generate command

In the Cookbook application we are considering a Cookbook which contains recipes for various dishes. The recipes have been divided into different categories, for example there is a recipe for ice tea which belongs to the category of beverages. There is a relationship which is created between a recipe and a category which can be expressed as an ice tea belongs to beverages. We can have many such recipes belonging to a single category, in this case many to one relationship is established.

<h1>Controllers for Cookbook Application</h1>
The Cookbook application starts by entering a URL in the browser which sends the request to the web server. Since our web server supports Rails application, it will hand over the control to a Rails controller.
A controller ‘controls’ the entire application by responding to the incoming requests as needed. For example, consider the following URL http ://localhost:3000/categories/show which is decoded by the controller to know that its action named show has been invoked.
All the controllers inherit only the ApplicationController which in turn inherits the ActionController::Base class. ActionContoller module provides the basic support for the controllers in Rails.
In our Cookbook application we generate Categories controller using the scaffold mechanism which populates the controller with the basic methods such as index, create, show, new, edit, update and destroy.
A simple example of index method is as follows:
<pre>
def index
@categories = Category.all

respond_to do |format|
format.html # index.html.erb
format.json { render json: @categories }
end
end

</pre>
In ruby, @ operator is used to declare instance variables. The index method makes use of @categories instance variable which is populated with all the records in the Category table. The respond_to method is used for responding to particular type of request. It contains a block and a variable |format| which determines whether the incoming request should be responded with HTML (when we are interacting with a user) or JSON format (if we are returning an object).
After executing the code, the controller will render a template of the same name. (For this example, the template is views/categories/index.html.erb).
Similarly the show method is defined as follows:
<pre>
def show
@category = Category.find(params[:id])

respond_to do |format|
format.html # show.html.erb
format.json { render json: @category }
end
end

</pre>
The show method is used to display a particular object. The show method needs to access database to search for the given object. This is done using the find method which takes params[:id] as argument. The params[:id] contains the id or primary key of the object which is passed as a parameter to look up in the database and the result is stored in the instance variable. The result is displayed by rendering the show.html.erb file.<br><br>
<b>Active Record</b><br>
In ruby, a program deals with objects which are mapped into database relational databases. This kind of mapping is facilitated by the Active Record.<br>Active Record maps the Rails classes in to database tables and rails objects into database records.
This makes it easy to perform actions on database tables by invoking the class methods. Another benefit of Active Record is database migration. Migrations can manage the evolution of a schema used by several physical databases. It’s a solution to the common problem of adding a field to make a new feature work in your local database, but being unsure of how to push that change to other developers and to the production server. With migrations, you can describe the transformations in self-contained classes that can be checked into version control systems and executed against another database that might be one, two, or five versions behind.You can find a lot more details about rails migration here[8].
<p>
<b>Method Pairs</b>
<br>There are couple of method pairs such as new-create and edit-update which are executed in sequence. In method pair one method is responsible for display preparation and the other method validates the data and attempts it to save in the database.
<pre>
def new
@category = Category.new

respond_to do |format|
format.html # new.html.erb
format.json { render json: @category }
end

end
</pre>
<pre>
def create
@category = Category.new(params[:category])

respond_to do |format|
if @category.save
format.html { redirect_to @category, notice: 'Category was successfully created.' }
format.json { render json: @category, status: :created, location: @category }
else
format.html { render action: "new" }
format.json { render json: @category.errors, status: :unprocessable_entity }
end
end
end

</pre>

The new and create methods are known as method pairs which execute in sequence. The new method is used to instantiate a new Category object whereas create method is used to successfully save the object to the database. After execution of the new method, the controller renders the new.html.erb file which displays a form to create a new Category object. The user enters the required information in the form and the object id is returned in the URL on submitting the form. Consider the following URL is generated on submitting the form: http: //localhost:3000/categories/3.
This means that Category object with id =3 will be created. The details of the object will be processed by the create method.
The controller invokes the create method to store the object in the database. An observation can be made about the @category variable in the create method.
<pre>
@category = Category.new(params[:category])
</pre>
The parameters passed in the URL after creating a new object is stored in the params hash (denoted by params[]). In this case the params[] contains an object with category_id = 3. The params[] assigns the data of object with category_id =3 to the instance variable. The data entered in the instance variable is validated using the @category.save method. If no errors are found then the object stored in the database and a message on successful creation of the object is displayed to the user. However, if the data entered in the object contains an error, the user is redirected to the new.html.erb page to resubmit the information and the errors are displayed.
Another example of such method pair is the edit and update methods. The edit method displays the table entry for an existing object, while the update method is invoked when the changes have been submitted.
</p>
<p>
<h1>Models of Cookbook Application</h1>
Model handles the data processing in a web application. Actions interact with the model to manipulate the data. Rails is capable of handling databases and this is facilitated by the model. You can base models on the Rails ActiveRecord module which contains support databases.
In our Cookbook application we have two models namely: Category and Recipe. They are represented by files category.rb and recipe.rb and each file is used to describe the relation between two classes. Let’s take a look at the two models
<br><b> category.rb</b>
<pre>
class Category < ActiveRecord::Base
has_many :recipes
end
</pre>

<b>recipe.rb</b>
<pre>class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>
</p>

*<b>Relationships in models</b>
<ul>one-to-one<br>
<pre>
class Syllabus < ActiveRecord::Base
belongs_to :course¬
end

class Course < ActiveRecord::Base
has_one :syllabus
end
</pre>
</ul>
<ul>many-many<br>
<pre>
class Student < ActiveRecord::Base
has_and_belongs_to_many :courses
end

class Course < ActiveRecord::Base
has_and_belongs_to_many :students
end
</pre></ul>

In Cookbook, we have many-one relationship between recipes and categories.
<p>
<h1>Views of Cookbook application</h1>
What is V in MVC? ‘V’ refers to views. Views are the actual interface that users can see. It is through views, that a user may request some data to be viewed or submits some data for processing.<br>
Views in rails are of the form file_name.html.erb. Here erb means embedded ruby. What html.erb denotes is some ruby code is embedded in HTML code. Like HTML, embedded ruby also uses tags to represent data. However, to distinguish it from the HTML code, ruby is embedded between <% %> if some non-assignment ruby operation is to be performed. If something needs to be displayed on screen, <%= %> is used.
Views are present in “app/views” folder in the rails application.
<br>
Name of the view files is same as the name of their respective controller. For e.g.:- if I have a controller movie with an action new, the corresponding view page will be new.html.erb in the app/views/movie directory.<br>
The Cookbook application views are as follows:

<b> Recipe Controller Views</b><br>
1. index.html.erb
<pre><nowiki><h1>Listing categories</h1>

<table>
<tr>
<th>Name</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @categories.each do |category| %>
<tr>
<td><%= category.name %></td>
<td><%= link_to 'Show', category %></td>
<td><%= link_to 'Edit', edit_category_path(category) %></td>
<td><%= link_to 'Destroy', category, method: :delete, data: { confirm: 'Are you sure?' } %></td>
</tr>
<% end %>
</table>
<br />

<%= link_to 'New Category', new_category_path %>
</nowiki></pre>

*<b><% @recipes.each do |recipe| %> </b>
Here @recipes is an instance variable of model recipe defined in index action of the controller ‘recipes’. It contains all the recipes currently present in our application. Then each recipe is taken from this instance variable and is assigned to the local variable recipe. All the subsequent lines display the recipe details (name, description and instruction).
<br>
*<b><%= link_to ‘Show’, recipe %> </b>
link_to is an ruby operator which is used to redirect the control to some other page. ‘Show’ is displayed as it is on the page and is an hyperlink. It links to a page pointed by recipe. The path is defined in the routes.rb file.
<br><br>
2. _form.html.erb
<br>
This is a partial. Partials are devices used for breaking the code in smaller, more manageable chunks. This helps in modularity and also maintain DRY principle[4]. With a partial, code for rendering a particular response is moved to its own file. So for e.g. we can use this same partial for creating and editing information, because the information involved is essentially the same.
<pre>
<%= form_for(@recipe) do |f| %>
<% if @recipe.errors.any? %>
<div id="error_explanation">
<h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>

<ul>
<% @recipe.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>

<div class="field">
<%= f.label :name %><br />
<%= f.text_field :name %>
</div>
<%= f.label :category %>
<%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %>
<div class="field">
<%= f.label :description %><br />
<%= f.text_field :description %>
</div>
<div class="field">
<%= f.label :instructions %><br />
<%= f.text_area :instructions %>
<%= f.submit %>
</div>
<% end %>
</pre>

* <b><%= form_for(@recipe) do |f| %></b>
This statement means to render a form for the instance variable @recipe.
If this page is being used for creating a new recipe, then the values for each key in the @recipe hash will be empty. If it is used for editing a recipe, @recipe will contain information corresponding to the recipe being edited.

*<b><% if @recipe.errors.any? %></b>
While saving an recipe or updating a recipe in the database, some violations may occur. Like the recipe name is left empty or its description is empty and so on. So while saving this information, database will signal some error. The errors are sent back to this page and are caught in @recipe.errors.any? statement.

*<b><%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %></b>
This statement creates a dropdown box.<br>
<ul>‘recipe’ : refers to the object to which the selected value is to be assigned. In this case , it is the recipe object</ul>
<ul>‘category_id’ : create a ‘category_id’ key in the recipe hash.</ul>
<ul>Category.all.collect {|c| [c[:name],c[:id]]} : recover all categories from the database and list them in the dropdown box. The value for each name is c[:id]. Whenever a category is selected by the user, its corresponding id is assigned to the ‘category_id’ key in the ‘recipe’ object.</ul>
<br>
3. new.html.erb<br>
This page is used to create a new recipe. This page simply renders the partial described above.
<pre>
<h1>New recipe</h1>
<%= render 'form' %>
<%= link_to 'Back', recipes_path %>
</pre>
*<b><%= render ‘form’ %> </b>
This statement renders the partial.
<br>
4. edit.html.erb
This page is used to edit a existing recipe. This page also renders the partial.
<pre>
<h1>Editing recipe</h1>
<%= render 'form' %>
<%= link_to 'Show', @recipe %> |
<%= link_to 'Back', recipes_path %>
</pre>
5. show.html.erb
This page is used to show a particular recipe requested by the user. The recipe requested is captured by the controller in the @recipe instance variable and is passed to this view.
<pre>
<p id="notice"><%= notice %></p>
<p>
<b>Name:</b>
<%= @recipe.name %>
</p>
<p>
<b>Description:</b>
<%= @recipe.description %>
</p>
<p>
<b>Instructions:</b>
<%= @recipe.instructions %>
</p>
<%= link_to 'Edit', edit_recipe_path(@recipe) %> |
<%= link_to 'Back', recipes_path %>
</pre>
<br>
<b>The Category Views are very similar to the recipe Views and can be created similarly.</b>

<h1>Conclusion</h1>

MVC was first proposed by Trygve Reenskaug in 1979. He broke applications into three types of components: models, which is responsible for maintaining the state of the application; views, which are responsible for generating a user interface; and controllers, which orchestrate the applications by receiving events from outside world, interact with model, and display an appropriate view to user. This separation of concerns led to far less computing, and in turn made the code easier to write and maintain.<br>
Use Ruby on Rails can implement MVC to build various types of web applications. The Cookbook is an easy starter. Readers can learn the basics of Ruby on Rails from this page.

<h1>References</h1>
*[1] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
*[2] http://en.wikipedia.org/wiki/Ruby_on_Rails
*[3] Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
*[4] http://en.wikipedia.org/wiki/Don't_repeat_yourself
*[5] http://guides.rubyonrails.org/getting_started.html
*[6] http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
*[7] http://en.wikipedia.org/wiki/Metaprogramming
*[8] http://net.tutsplus.com/tutorials/other/mvc-for-noobs/
*[9] Hotzner, S. (2007). Beginnning ruby on rail, Indianapolis: Wiley Publishing Inc
<br><br>

The old wiki can be found here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4d_ch.

CSC/ECE 517 Fall 2012/ch1b 1w38 nm

2012-10-04T01:42:26Z

Nmsarda:

<h1>Introduction</h1>
This page is aimed at asserting the importance of Model View Controller Architecture and how MVC is implemented in Cookbook application.

<h2>Model View Controller (MVC) Architecture</h2>

The purpose of creating MVC architecture is to have clear separation between the responsibilities of business logic and representation. In a nutshell the responsibilities are mentioned as below:

[[File:MVC.png|frame|none|MVC Responsibilities[8]]]

Model-View-Controller (MVC)[1] is an architectural pattern used in software engineering.In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface.<br>
The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. Having described the responsibilities of three components let’s take a look how these components interact with each other.

[[File:MVC_architecture.PNG|frame|none|MVC Architecture[9]]]

<h2>Ruby on Rails</h2>

Ruby on Rails[2] is an MVC framework. Rails enforces a structure for application, it helps to knits the models, views, and controllers as separate chunks of functionality while the program executes. No more external configuration needed. Rails is packed with features that make you more productive, with many of the following features building on one other.<br>
<b>Metaprogramming[7]:</b> Other frameworks use extensive code generation from scratch. Metaprogramming[9] techniques use programs to write programs. Ruby is one of the best languages for metaprogramming, and Rails uses this capability well. Rails also uses code generation but relies much more on metaprogramming for the heavy lifting.<br>
<b>Active Record:</b> Rails introduces the Active Record[6] framework, which saves objects to the database. The Rails version of Active Record discovers the columns in a database schema and automatically attaches them to your domain objects using metaprogramming.<br>
<b>Convention over configuration:</b> Most web development frameworks for .NET or Java force you to write pages of configuration code. If you follow suggested naming conventions, Rails doesn't need much configuration.<br>
<b>Scaffolding:</b> You often create temporary code in the early stages of development to help get an application up quickly and see how major components work together. Rails automatically creates much of the scaffolding you'll need.<br>
<b>Built-in testing:</b> Rails creates simple automated tests you can then extend. Rails also provides supporting code called harnesses and fixtures that make test cases easier to write and run. Ruby can then execute all your automated tests with the rake utility.<br>
<b>Three environments:</b> Rails gives you three default environments: development, testing, and production. Each behaves slightly differently, making your entire software development cycle easier. For example, Rails creates a fresh copy of the Test database for each test run.

<h1>Cookbook Application</h1>
Cookbook Application is a very basic Ruby on Rails application. It is a great way to understand the nuances that ‘Ruby’ has to offer. It is built keeping in mind that the reader is new to the world of ruby and is developing his/her first Ruby on Rails application.
The motive of this wiki page is to make the reader understand how the Cookbook application was built. And on the way to building this application, user will be introduced to some key concepts like Model, Views and Controllers. At the end of this page, reader must fairly be ready to start building his/her basic Ruby on Rails application.

<h2>A simple application to start -- Cookbook application</h2>

Start a new project. While creating a new project, remember to select Rails Application option as follows

[[File:Start_application.png|frame|none|Start a new Application]]

When we create a Rails application, rails automatically help us create a brunch of files and folders as follows:

[[File:Listing_of_cookbook_application.png|frame|none|Listing_of_cookbook_application]]

We mainly use the app directory. This is where the heart of the application is stored i.e. Models, Views and controllers.

<h2>Using scaffold to create framework</h2>
Rails scaffolding is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job.<br>
In Rubymine, we can create a scaffold by right clicking on the current Project->New->Run Rails Generator ->scaffold. This will open a dialog box to create a scaffold where we can enter the name and the attributes along with their data type. Once the scaffold has been created RubyMine will generate the model, view and controller files respectively. These files do not contain any specific methods but they provide a framework which is useful for general applications. The user can modify the MVC behavior according to his application requirements. Each scaffold has create, read, update and delete methods declared in the controller class. A user can modify the behavior of the controller through these methods.
<br>

[[File:Create_Scaffold.png|frame|none|Creating a new scaffold]]<br><br>
[[File:Scaffold.png|frame|left|Scaffold]] [[File:New_Scaffold_Categories.png|frame|center|Creating scaffold for categories]]<br>

<h2>Working without scaffold</h2>

Or you don't want to create a fully standard framework with scaffold, then you can use RubyMine generate command, you can create merely model, controller and view using generate command, there are many command included in the generate that you can use, expect those MVC, you can also crate migration, assets, intergration_test and performance_test. Or you don't want to create a empty controller and writing code all yourself you can also use scaffold_controller to create controller
Here is an example. You have create the Model and everything on your own without using the scaffolding in Ruby on Rails. You create the following class:

<pre>
class Dog < ActiveRecord::Base
end
</pre>
You can add a table Dogs. by
<pre>rails g migration CreateDogs</pre>
which also a generate command

In the Cookbook application we are considering a Cookbook which contains recipes for various dishes. The recipes have been divided into different categories, for example there is a recipe for ice tea which belongs to the category of beverages. There is a relationship which is created between a recipe and a category which can be expressed as an ice tea belongs to beverages. We can have many such recipes belonging to a single category, in this case many to one relationship is established.

<h1>Controllers for Cookbook Application</h1>
The Cookbook application starts by entering a URL in the browser which sends the request to the web server. Since our web server supports Rails application, it will hand over the control to a Rails controller.
A controller ‘controls’ the entire application by responding to the incoming requests as needed. For example, consider the following URL http ://localhost:3000/categories/show which is decoded by the controller to know that its action named show has been invoked.
All the controllers inherit only the ApplicationController which in turn inherits the ActionController::Base class. ActionContoller module provides the basic support for the controllers in Rails.
In our Cookbook application we generate Categories controller using the scaffold mechanism which populates the controller with the basic methods such as index, create, show, new, edit, update and destroy.
A simple example of index method is as follows:
<pre>
def index
@categories = Category.all

respond_to do |format|
format.html # index.html.erb
format.json { render json: @categories }
end
end

</pre>
In ruby, @ operator is used to declare instance variables. The index method makes use of @categories instance variable which is populated with all the records in the Category table. The respond_to method is used for responding to particular type of request. It contains a block and a variable |format| which determines whether the incoming request should be responded with HTML (when we are interacting with a user) or JSON format (if we are returning an object).
After executing the code, the controller will render a template of the same name. (For this example, the template is views/categories/index.html.erb).
Similarly the show method is defined as follows:
<pre>
def show
@category = Category.find(params[:id])

respond_to do |format|
format.html # show.html.erb
format.json { render json: @category }
end
end

</pre>
The show method is used to display a particular object. The show method needs to access database to search for the given object. This is done using the find method which takes params[:id] as argument. The params[:id] contains the id or primary key of the object which is passed as a parameter to look up in the database and the result is stored in the instance variable. The result is displayed by rendering the show.html.erb file.<br><br>
<b>Active Record</b><br>
In ruby, a program deals with objects which are mapped into database relational databases. This kind of mapping is facilitated by the Active Record.<br>Active Record maps the Rails classes in to database tables and rails objects into database records.
This makes it easy to perform actions on database tables by invoking the class methods. Another benefit of Active Record is database migration. Migrations can manage the evolution of a schema used by several physical databases. It’s a solution to the common problem of adding a field to make a new feature work in your local database, but being unsure of how to push that change to other developers and to the production server. With migrations, you can describe the transformations in self-contained classes that can be checked into version control systems and executed against another database that might be one, two, or five versions behind.You can find a lot more details about rails migration here[8].
<p>
<b>Method Pairs</b>
<br>There are couple of method pairs such as new-create and edit-update which are executed in sequence. In method pair one method is responsible for display preparation and the other method validates the data and attempts it to save in the database.
<pre>
def new
@category = Category.new

respond_to do |format|
format.html # new.html.erb
format.json { render json: @category }
end

end
</pre>
<pre>
def create
@category = Category.new(params[:category])

respond_to do |format|
if @category.save
format.html { redirect_to @category, notice: 'Category was successfully created.' }
format.json { render json: @category, status: :created, location: @category }
else
format.html { render action: "new" }
format.json { render json: @category.errors, status: :unprocessable_entity }
end
end
end

</pre>

The new and create methods are known as method pairs which execute in sequence. The new method is used to instantiate a new Category object whereas create method is used to successfully save the object to the database. After execution of the new method, the controller renders the new.html.erb file which displays a form to create a new Category object. The user enters the required information in the form and the object id is returned in the URL on submitting the form. Consider the following URL is generated on submitting the form: http: //localhost:3000/categories/3.
This means that Category object with id =3 will be created. The details of the object will be processed by the create method.
The controller invokes the create method to store the object in the database. An observation can be made about the @category variable in the create method.
<pre>
@category = Category.new(params[:category])
</pre>
The parameters passed in the URL after creating a new object is stored in the params hash (denoted by params[]). In this case the params[] contains an object with category_id = 3. The params[] assigns the data of object with category_id =3 to the instance variable. The data entered in the instance variable is validated using the @category.save method. If no errors are found then the object stored in the database and a message on successful creation of the object is displayed to the user. However, if the data entered in the object contains an error, the user is redirected to the new.html.erb page to resubmit the information and the errors are displayed.
Another example of such method pair is the edit and update methods. The edit method displays the table entry for an existing object, while the update method is invoked when the changes have been submitted.
</p>
<p>
<h1>Models of Cookbook Application</h1>
Model handles the data processing in a web application. Actions interact with the model to manipulate the data. Rails is capable of handling databases and this is facilitated by the model. You can base models on the Rails ActiveRecord module which contains support databases.
In our Cookbook application we have two models namely: Category and Recipe. They are represented by files category.rb and recipe.rb and each file is used to describe the relation between two classes. Let’s take a look at the two models
<br><b> category.rb</b>
<pre>
class Category < ActiveRecord::Base
has_many :recipes
end
</pre>

<b>recipe.rb</b>
<pre>class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>
</p>

*<b>Relationships in models</b>
<ul>one-to-one<br>
<pre>
class Syllabus < ActiveRecord::Base
belongs_to :course¬
end

class Course < ActiveRecord::Base
has_one :syllabus
end
</pre>
</ul>
<ul>many-many<br>
<pre>
class Student < ActiveRecord::Base
has_and_belongs_to_many :courses
end

class Course < ActiveRecord::Base
has_and_belongs_to_many :students
end
</pre></ul>

In Cookbook, we have many-one relationship between recipes and categories.
<p>
<h1>Views of Cookbook application</h1>
What is V in MVC? ‘V’ refers to views. Views are the actual interface that users can see. It is through views, that a user may request some data to be viewed or submits some data for processing.<br>
Views in rails are of the form file_name.html.erb. Here erb means embedded ruby. What html.erb denotes is some ruby code is embedded in HTML code. Like HTML, embedded ruby also uses tags to represent data. However, to distinguish it from the HTML code, ruby is embedded between <% %> if some non-assignment ruby operation is to be performed. If something needs to be displayed on screen, <%= %> is used.
Views are present in “app/views” folder in the rails application.
<br>
Name of the view files is same as the name of their respective controller. For e.g.:- if I have a controller movie with an action new, the corresponding view page will be new.html.erb in the app/views/movie directory.<br>
The Cookbook application views are as follows:

<b> Recipe Controller Views</b><br>
1. index.html.erb
<pre><nowiki><h1>Listing categories</h1>

<table>
<tr>
<th>Name</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @categories.each do |category| %>
<tr>
<td><%= category.name %></td>
<td><%= link_to 'Show', category %></td>
<td><%= link_to 'Edit', edit_category_path(category) %></td>
<td><%= link_to 'Destroy', category, method: :delete, data: { confirm: 'Are you sure?' } %></td>
</tr>
<% end %>
</table>
<br />

<%= link_to 'New Category', new_category_path %>
</nowiki></pre>

*<b><% @recipes.each do |recipe| %> </b>
Here @recipes is an instance variable of model recipe defined in index action of the controller ‘recipes’. It contains all the recipes currently present in our application. Then each recipe is taken from this instance variable and is assigned to the local variable recipe. All the subsequent lines display the recipe details (name, description and instruction).
<br>
*<b><%= link_to ‘Show’, recipe %> </b>
link_to is an ruby operator which is used to redirect the control to some other page. ‘Show’ is displayed as it is on the page and is an hyperlink. It links to a page pointed by recipe. The path is defined in the routes.rb file.
<br><br>
2. _form.html.erb
<br>
This is a partial. Partials are devices used for breaking the code in smaller, more manageable chunks. This helps in modularity and also maintain DRY principle[4]. With a partial, code for rendering a particular response is moved to its own file. So for e.g. we can use this same partial for creating and editing information, because the information involved is essentially the same.
<pre>
<%= form_for(@recipe) do |f| %>
<% if @recipe.errors.any? %>
<div id="error_explanation">
<h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>

<ul>
<% @recipe.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>

<div class="field">
<%= f.label :name %><br />
<%= f.text_field :name %>
</div>
<%= f.label :category %>
<%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %>
<div class="field">
<%= f.label :description %><br />
<%= f.text_field :description %>
</div>
<div class="field">
<%= f.label :instructions %><br />
<%= f.text_area :instructions %>
<%= f.submit %>
</div>
<% end %>
</pre>

* <b><%= form_for(@recipe) do |f| %></b>
This statement means to render a form for the instance variable @recipe.
If this page is being used for creating a new recipe, then the values for each key in the @recipe hash will be empty. If it is used for editing a recipe, @recipe will contain information corresponding to the recipe being edited.

*<b><% if @recipe.errors.any? %></b>
While saving an recipe or updating a recipe in the database, some violations may occur. Like the recipe name is left empty or its description is empty and so on. So while saving this information, database will signal some error. The errors are sent back to this page and are caught in @recipe.errors.any? statement.

*<b><%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %></b>
This statement creates a dropdown box.<br>
<ul>‘recipe’ : refers to the object to which the selected value is to be assigned. In this case , it is the recipe object</ul>
<ul>‘category_id’ : create a ‘category_id’ key in the recipe hash.</ul>
<ul>Category.all.collect {|c| [c[:name],c[:id]]} : recover all categories from the database and list them in the dropdown box. The value for each name is c[:id]. Whenever a category is selected by the user, its corresponding id is assigned to the ‘category_id’ key in the ‘recipe’ object.</ul>
<br>
3. new.html.erb<br>
This page is used to create a new recipe. This page simply renders the partial described above.
<pre>
<h1>New recipe</h1>
<%= render 'form' %>
<%= link_to 'Back', recipes_path %>
</pre>
*<b><%= render ‘form’ %> </b>
This statement renders the partial.
<br>
4. edit.html.erb
This page is used to edit a existing recipe. This page also renders the partial.
<pre>
<h1>Editing recipe</h1>
<%= render 'form' %>
<%= link_to 'Show', @recipe %> |
<%= link_to 'Back', recipes_path %>
</pre>
5. show.html.erb
This page is used to show a particular recipe requested by the user. The recipe requested is captured by the controller in the @recipe instance variable and is passed to this view.
<pre>
<p id="notice"><%= notice %></p>
<p>
<b>Name:</b>
<%= @recipe.name %>
</p>
<p>
<b>Description:</b>
<%= @recipe.description %>
</p>
<p>
<b>Instructions:</b>
<%= @recipe.instructions %>
</p>
<%= link_to 'Edit', edit_recipe_path(@recipe) %> |
<%= link_to 'Back', recipes_path %>
</pre>
<br>
<b>The Category Views are very similar to the recipe Views and can be created similarly.</b>

<h1>Conclusion</h1>

MVC was first proposed by Trygve Reenskaug in 1979. He broke applications into three types of components: models, which is responsible for maintaining the state of the application; views, which are responsible for generating a user interface; and controllers, which orchestrate the applications by receiving events from outside world, interact with model, and display an appropriate view to user. This separation of concerns led to far less computing, and in turn made the code easier to write and maintain.<br>
Use Ruby on Rails can implement MVC to build various types of web applications. The Cookbook is an easy starter. Readers can learn the basics of Ruby on Rails from this page.

<h1>References</h1>
*[1] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
*[2] http://en.wikipedia.org/wiki/Ruby_on_Rails
*[3] Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
*[4] http://en.wikipedia.org/wiki/Don't_repeat_yourself
*[5] http://guides.rubyonrails.org/getting_started.html
*[6] http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
*[7] http://en.wikipedia.org/wiki/Metaprogramming
*[8] http://net.tutsplus.com/tutorials/other/mvc-for-noobs/
*[9] Hotzner, S. (2007). Beginnning ruby on rail, Indianapolis: Wiley Publishing Inc
<br><br>

The old wiki can be found here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4d_ch.

CSC/ECE 517 Fall 2012/ch1b 1w38 nm

2012-10-04T01:40:38Z

Nmsarda:

<h1>Introduction</h1>
This page is aimed at asserting the importance of Model View Controller Architecture and how MVC is implemented in Cookbook application.

<h2>Model View Controller (MVC) Architecture</h2>

The purpose of creating MVC architecture is to have clear separation between the responsibilities of business logic and representation. In a nutshell the responsibilities are mentioned as below:

[[File:MVC.png|frame|none|MVC Responsibilities[8]]]

Model-View-Controller (MVC)[1] is an architectural pattern used in software engineering.In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface.<br>
The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. Having described the responsibilities of three components let’s take a look how these components interact with each other.

[[File:MVC_architecture.PNG|frame|none|MVC Architecture]]

<h2>Ruby on Rails</h2>

Ruby on Rails[2] is an MVC framework. Rails enforces a structure for application, it helps to knits the models, views, and controllers as separate chunks of functionality while the program executes. No more external configuration needed. Rails is packed with features that make you more productive, with many of the following features building on one other.<br>
<b>Metaprogramming[7]:</b> Other frameworks use extensive code generation from scratch. Metaprogramming[9] techniques use programs to write programs. Ruby is one of the best languages for metaprogramming, and Rails uses this capability well. Rails also uses code generation but relies much more on metaprogramming for the heavy lifting.<br>
<b>Active Record:</b> Rails introduces the Active Record[6] framework, which saves objects to the database. The Rails version of Active Record discovers the columns in a database schema and automatically attaches them to your domain objects using metaprogramming.<br>
<b>Convention over configuration:</b> Most web development frameworks for .NET or Java force you to write pages of configuration code. If you follow suggested naming conventions, Rails doesn't need much configuration.<br>
<b>Scaffolding:</b> You often create temporary code in the early stages of development to help get an application up quickly and see how major components work together. Rails automatically creates much of the scaffolding you'll need.<br>
<b>Built-in testing:</b> Rails creates simple automated tests you can then extend. Rails also provides supporting code called harnesses and fixtures that make test cases easier to write and run. Ruby can then execute all your automated tests with the rake utility.<br>
<b>Three environments:</b> Rails gives you three default environments: development, testing, and production. Each behaves slightly differently, making your entire software development cycle easier. For example, Rails creates a fresh copy of the Test database for each test run.

<h1>Cookbook Application</h1>
Cookbook Application is a very basic Ruby on Rails application. It is a great way to understand the nuances that ‘Ruby’ has to offer. It is built keeping in mind that the reader is new to the world of ruby and is developing his/her first Ruby on Rails application.
The motive of this wiki page is to make the reader understand how the Cookbook application was built. And on the way to building this application, user will be introduced to some key concepts like Model, Views and Controllers. At the end of this page, reader must fairly be ready to start building his/her basic Ruby on Rails application.

<h2>A simple application to start -- Cookbook application</h2>

Start a new project. While creating a new project, remember to select Rails Application option as follows

[[File:Start_application.png|frame|none|Start a new Application]]

When we create a Rails application, rails automatically help us create a brunch of files and folders as follows:

[[File:Listing_of_cookbook_application.png|frame|none|Listing_of_cookbook_application]]

We mainly use the app directory. This is where the heart of the application is stored i.e. Models, Views and controllers.

<h2>Using scaffold to create framework</h2>
Rails scaffolding is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job.<br>
In Rubymine, we can create a scaffold by right clicking on the current Project->New->Run Rails Generator ->scaffold. This will open a dialog box to create a scaffold where we can enter the name and the attributes along with their data type. Once the scaffold has been created RubyMine will generate the model, view and controller files respectively. These files do not contain any specific methods but they provide a framework which is useful for general applications. The user can modify the MVC behavior according to his application requirements. Each scaffold has create, read, update and delete methods declared in the controller class. A user can modify the behavior of the controller through these methods.
<br>

[[File:Create_Scaffold.png|frame|none|Creating a new scaffold]]<br><br>
[[File:Scaffold.png|frame|left|Scaffold]] [[File:New_Scaffold_Categories.png|frame|center|Creating scaffold for categories]]<br>

<h2>Working without scaffold</h2>

Or you don't want to create a fully standard framework with scaffold, then you can use RubyMine generate command, you can create merely model, controller and view using generate command, there are many command included in the generate that you can use, expect those MVC, you can also crate migration, assets, intergration_test and performance_test. Or you don't want to create a empty controller and writing code all yourself you can also use scaffold_controller to create controller
Here is an example. You have create the Model and everything on your own without using the scaffolding in Ruby on Rails. You create the following class:

<pre>
class Dog < ActiveRecord::Base
end
</pre>
You can add a table Dogs. by
<pre>rails g migration CreateDogs</pre>
which also a generate command

In the Cookbook application we are considering a Cookbook which contains recipes for various dishes. The recipes have been divided into different categories, for example there is a recipe for ice tea which belongs to the category of beverages. There is a relationship which is created between a recipe and a category which can be expressed as an ice tea belongs to beverages. We can have many such recipes belonging to a single category, in this case many to one relationship is established.

<h1>Controllers for Cookbook Application</h1>
The Cookbook application starts by entering a URL in the browser which sends the request to the web server. Since our web server supports Rails application, it will hand over the control to a Rails controller.
A controller ‘controls’ the entire application by responding to the incoming requests as needed. For example, consider the following URL http ://localhost:3000/categories/show which is decoded by the controller to know that its action named show has been invoked.
All the controllers inherit only the ApplicationController which in turn inherits the ActionController::Base class. ActionContoller module provides the basic support for the controllers in Rails.
In our Cookbook application we generate Categories controller using the scaffold mechanism which populates the controller with the basic methods such as index, create, show, new, edit, update and destroy.
A simple example of index method is as follows:
<pre>
def index
@categories = Category.all

respond_to do |format|
format.html # index.html.erb
format.json { render json: @categories }
end
end

</pre>
In ruby, @ operator is used to declare instance variables. The index method makes use of @categories instance variable which is populated with all the records in the Category table. The respond_to method is used for responding to particular type of request. It contains a block and a variable |format| which determines whether the incoming request should be responded with HTML (when we are interacting with a user) or JSON format (if we are returning an object).
After executing the code, the controller will render a template of the same name. (For this example, the template is views/categories/index.html.erb).
Similarly the show method is defined as follows:
<pre>
def show
@category = Category.find(params[:id])

respond_to do |format|
format.html # show.html.erb
format.json { render json: @category }
end
end

</pre>
The show method is used to display a particular object. The show method needs to access database to search for the given object. This is done using the find method which takes params[:id] as argument. The params[:id] contains the id or primary key of the object which is passed as a parameter to look up in the database and the result is stored in the instance variable. The result is displayed by rendering the show.html.erb file.<br><br>
<b>Active Record</b><br>
In ruby, a program deals with objects which are mapped into database relational databases. This kind of mapping is facilitated by the Active Record.<br>Active Record maps the Rails classes in to database tables and rails objects into database records.
This makes it easy to perform actions on database tables by invoking the class methods. Another benefit of Active Record is database migration. Migrations can manage the evolution of a schema used by several physical databases. It’s a solution to the common problem of adding a field to make a new feature work in your local database, but being unsure of how to push that change to other developers and to the production server. With migrations, you can describe the transformations in self-contained classes that can be checked into version control systems and executed against another database that might be one, two, or five versions behind.You can find a lot more details about rails migration here[8].
<p>
<b>Method Pairs</b>
<br>There are couple of method pairs such as new-create and edit-update which are executed in sequence. In method pair one method is responsible for display preparation and the other method validates the data and attempts it to save in the database.
<pre>
def new
@category = Category.new

respond_to do |format|
format.html # new.html.erb
format.json { render json: @category }
end

end
</pre>
<pre>
def create
@category = Category.new(params[:category])

respond_to do |format|
if @category.save
format.html { redirect_to @category, notice: 'Category was successfully created.' }
format.json { render json: @category, status: :created, location: @category }
else
format.html { render action: "new" }
format.json { render json: @category.errors, status: :unprocessable_entity }
end
end
end

</pre>

The new and create methods are known as method pairs which execute in sequence. The new method is used to instantiate a new Category object whereas create method is used to successfully save the object to the database. After execution of the new method, the controller renders the new.html.erb file which displays a form to create a new Category object. The user enters the required information in the form and the object id is returned in the URL on submitting the form. Consider the following URL is generated on submitting the form: http: //localhost:3000/categories/3.
This means that Category object with id =3 will be created. The details of the object will be processed by the create method.
The controller invokes the create method to store the object in the database. An observation can be made about the @category variable in the create method.
<pre>
@category = Category.new(params[:category])
</pre>
The parameters passed in the URL after creating a new object is stored in the params hash (denoted by params[]). In this case the params[] contains an object with category_id = 3. The params[] assigns the data of object with category_id =3 to the instance variable. The data entered in the instance variable is validated using the @category.save method. If no errors are found then the object stored in the database and a message on successful creation of the object is displayed to the user. However, if the data entered in the object contains an error, the user is redirected to the new.html.erb page to resubmit the information and the errors are displayed.
Another example of such method pair is the edit and update methods. The edit method displays the table entry for an existing object, while the update method is invoked when the changes have been submitted.
</p>
<p>
<h1>Models of Cookbook Application</h1>
Model handles the data processing in a web application. Actions interact with the model to manipulate the data. Rails is capable of handling databases and this is facilitated by the model. You can base models on the Rails ActiveRecord module which contains support databases.
In our Cookbook application we have two models namely: Category and Recipe. They are represented by files category.rb and recipe.rb and each file is used to describe the relation between two classes. Let’s take a look at the two models
<br><b> category.rb</b>
<pre>
class Category < ActiveRecord::Base
has_many :recipes
end
</pre>

<b>recipe.rb</b>
<pre>class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>
</p>

*<b>Relationships in models</b>
<ul>one-to-one<br>
<pre>
class Syllabus < ActiveRecord::Base
belongs_to :course¬
end

class Course < ActiveRecord::Base
has_one :syllabus
end
</pre>
</ul>
<ul>many-many<br>
<pre>
class Student < ActiveRecord::Base
has_and_belongs_to_many :courses
end

class Course < ActiveRecord::Base
has_and_belongs_to_many :students
end
</pre></ul>

In Cookbook, we have many-one relationship between recipes and categories.
<p>
<h1>Views of Cookbook application</h1>
What is V in MVC? ‘V’ refers to views. Views are the actual interface that users can see. It is through views, that a user may request some data to be viewed or submits some data for processing.<br>
Views in rails are of the form file_name.html.erb. Here erb means embedded ruby. What html.erb denotes is some ruby code is embedded in HTML code. Like HTML, embedded ruby also uses tags to represent data. However, to distinguish it from the HTML code, ruby is embedded between <% %> if some non-assignment ruby operation is to be performed. If something needs to be displayed on screen, <%= %> is used.
Views are present in “app/views” folder in the rails application.
<br>
Name of the view files is same as the name of their respective controller. For e.g.:- if I have a controller movie with an action new, the corresponding view page will be new.html.erb in the app/views/movie directory.<br>
The Cookbook application views are as follows:

<b> Recipe Controller Views</b><br>
1. index.html.erb
<pre><nowiki><h1>Listing categories</h1>

<table>
<tr>
<th>Name</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @categories.each do |category| %>
<tr>
<td><%= category.name %></td>
<td><%= link_to 'Show', category %></td>
<td><%= link_to 'Edit', edit_category_path(category) %></td>
<td><%= link_to 'Destroy', category, method: :delete, data: { confirm: 'Are you sure?' } %></td>
</tr>
<% end %>
</table>
<br />

<%= link_to 'New Category', new_category_path %>
</nowiki></pre>

*<b><% @recipes.each do |recipe| %> </b>
Here @recipes is an instance variable of model recipe defined in index action of the controller ‘recipes’. It contains all the recipes currently present in our application. Then each recipe is taken from this instance variable and is assigned to the local variable recipe. All the subsequent lines display the recipe details (name, description and instruction).
<br>
*<b><%= link_to ‘Show’, recipe %> </b>
link_to is an ruby operator which is used to redirect the control to some other page. ‘Show’ is displayed as it is on the page and is an hyperlink. It links to a page pointed by recipe. The path is defined in the routes.rb file.
<br><br>
2. _form.html.erb
<br>
This is a partial. Partials are devices used for breaking the code in smaller, more manageable chunks. This helps in modularity and also maintain DRY principle[4]. With a partial, code for rendering a particular response is moved to its own file. So for e.g. we can use this same partial for creating and editing information, because the information involved is essentially the same.
<pre>
<%= form_for(@recipe) do |f| %>
<% if @recipe.errors.any? %>
<div id="error_explanation">
<h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>

<ul>
<% @recipe.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>

<div class="field">
<%= f.label :name %><br />
<%= f.text_field :name %>
</div>
<%= f.label :category %>
<%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %>
<div class="field">
<%= f.label :description %><br />
<%= f.text_field :description %>
</div>
<div class="field">
<%= f.label :instructions %><br />
<%= f.text_area :instructions %>
<%= f.submit %>
</div>
<% end %>
</pre>

* <b><%= form_for(@recipe) do |f| %></b>
This statement means to render a form for the instance variable @recipe.
If this page is being used for creating a new recipe, then the values for each key in the @recipe hash will be empty. If it is used for editing a recipe, @recipe will contain information corresponding to the recipe being edited.

*<b><% if @recipe.errors.any? %></b>
While saving an recipe or updating a recipe in the database, some violations may occur. Like the recipe name is left empty or its description is empty and so on. So while saving this information, database will signal some error. The errors are sent back to this page and are caught in @recipe.errors.any? statement.

*<b><%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %></b>
This statement creates a dropdown box.<br>
<ul>‘recipe’ : refers to the object to which the selected value is to be assigned. In this case , it is the recipe object</ul>
<ul>‘category_id’ : create a ‘category_id’ key in the recipe hash.</ul>
<ul>Category.all.collect {|c| [c[:name],c[:id]]} : recover all categories from the database and list them in the dropdown box. The value for each name is c[:id]. Whenever a category is selected by the user, its corresponding id is assigned to the ‘category_id’ key in the ‘recipe’ object.</ul>
<br>
3. new.html.erb<br>
This page is used to create a new recipe. This page simply renders the partial described above.
<pre>
<h1>New recipe</h1>
<%= render 'form' %>
<%= link_to 'Back', recipes_path %>
</pre>
*<b><%= render ‘form’ %> </b>
This statement renders the partial.
<br>
4. edit.html.erb
This page is used to edit a existing recipe. This page also renders the partial.
<pre>
<h1>Editing recipe</h1>
<%= render 'form' %>
<%= link_to 'Show', @recipe %> |
<%= link_to 'Back', recipes_path %>
</pre>
5. show.html.erb
This page is used to show a particular recipe requested by the user. The recipe requested is captured by the controller in the @recipe instance variable and is passed to this view.
<pre>
<p id="notice"><%= notice %></p>
<p>
<b>Name:</b>
<%= @recipe.name %>
</p>
<p>
<b>Description:</b>
<%= @recipe.description %>
</p>
<p>
<b>Instructions:</b>
<%= @recipe.instructions %>
</p>
<%= link_to 'Edit', edit_recipe_path(@recipe) %> |
<%= link_to 'Back', recipes_path %>
</pre>
<br>
<b>The Category Views are very similar to the recipe Views and can be created similarly.</b>

<h1>Conclusion</h1>

MVC was first proposed by Trygve Reenskaug in 1979. He broke applications into three types of components: models, which is responsible for maintaining the state of the application; views, which are responsible for generating a user interface; and controllers, which orchestrate the applications by receiving events from outside world, interact with model, and display an appropriate view to user. This separation of concerns led to far less computing, and in turn made the code easier to write and maintain.<br>
Use Ruby on Rails can implement MVC to build various types of web applications. The Cookbook is an easy starter. Readers can learn the basics of Ruby on Rails from this page.

<h1>References</h1>
*[1] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
*[2] http://en.wikipedia.org/wiki/Ruby_on_Rails
*[3] Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
*[4] http://en.wikipedia.org/wiki/Don't_repeat_yourself
*[5] http://guides.rubyonrails.org/getting_started.html
*[6] http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
*[7] http://en.wikipedia.org/wiki/Metaprogramming
*[8] http://net.tutsplus.com/tutorials/other/mvc-for-noobs/
<br><br>

The old wiki can be found here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4d_ch.

CSC/ECE 517 Fall 2012

2012-10-04T01:31:34Z

Nmsarda:

*[[CSC/ECE 517 Fall 2012/ch1 n xx]]
*[[CSC/ECE 517 Fall 2012/ch1 1w1 rk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w20 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w5 su]]
*[[CSC/ECE 517 Fall 2012/ch1 1w6 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w4 aj]]
*[[CSC/ECE 517 Fall 2012/ch1 1w7 am]]
*[[CSC/ECE 517 Fall 2012/ch1 1w8 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w9 av]]
*[[CSC/ECE 517 Fall 2012/ch1 1w10 pk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w11 ap]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w12 mv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w14 gv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w17 ir]]
*[[CSC/ECE 517 Fall 2012/ch1 1w18 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w22 an]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 wi]]
*[[CSC/ECE 517 Fall 2012/ch1 1w31 sa]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w16 br]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w23 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w24 nr]]
*[[CSC/ECE 517 Fall 2012/ch1 1w15 rt]]
*[[CSC/ECE 517 Fall 2012/ch1 1w3 pl]]
*[[CSC/ECE 517 Fall 2012/ch1 1w32 cm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w37 ss]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w67 ks]]

*[[CSC/ECE 517 Fall 2012/ch1 1w27 ms]]
*[[CSC/ECE 517 Fall 2012/ch1 1w29 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w33 op]]
*[[CSC/ECE 517 Fall 2012/ch1 1w19 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w34 vd]]
*[[CSC/ECE 517 Fall 2012/ch1 1w35 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w30 rp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w47 sk]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w69 mv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w44 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w45 is]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w53 kc]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 ar]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w39 sn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w54 go]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w56 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w64 nn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w66 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w42 js]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w46 sm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w71 gs]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w63 dv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w55 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w57 mp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w52 an]]
*[[CSC/ECE_517_Fall_2012/ch1b 1w38 nm]]

CSC/ECE 517 Fall 2012

2012-10-04T01:30:59Z

Nmsarda:

CSC/ECE 517 Fall 2012/ch1b 1w38 nm

2012-10-04T01:30:25Z

Nmsarda: Created page with "<h1>Introduction</h1> This page is aimed at asserting the importance of Model View Controller Architecture and how MVC is implemented in Cookbook application. <h2>Model View Con..."

<h1>Introduction</h1>
This page is aimed at asserting the importance of Model View Controller Architecture and how MVC is implemented in Cookbook application.

<h2>Model View Controller (MVC) Architecture</h2>

The purpose of creating MVC architecture is to have clear separation between the responsibilities of business logic and representation. In a nutshell the responsibilities are mentioned as below:

[[File:MVC.png|frame|none|MVC Responsibilities[8]]]

Model-View-Controller (MVC)[1] is an architectural pattern used in software engineering.In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface.<br>
The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. Having described the responsibilities of three components let’s take a look how these components interact with each other.

[[File:MVC_architecture.PNG|frame|none|MVC Architecture]]

<h2>Ruby on Rails</h2>

Ruby on Rails[2] is an MVC framework. Rails enforces a structure for application, it helps to knits the models, views, and controllers as separate chunks of functionality while the program executes. No more external configuration needed. Rails is packed with features that make you more productive, with many of the following features building on one other.<br>
<b>Metaprogramming[7]:</b> Other frameworks use extensive code generation from scratch. Metaprogramming[9] techniques use programs to write programs. Ruby is one of the best languages for metaprogramming, and Rails uses this capability well. Rails also uses code generation but relies much more on metaprogramming for the heavy lifting.<br>
<b>Active Record:</b> Rails introduces the Active Record[6] framework, which saves objects to the database. The Rails version of Active Record discovers the columns in a database schema and automatically attaches them to your domain objects using metaprogramming.<br>
<b>Convention over configuration:</b> Most web development frameworks for .NET or Java force you to write pages of configuration code. If you follow suggested naming conventions, Rails doesn't need much configuration.<br>
<b>Scaffolding:</b> You often create temporary code in the early stages of development to help get an application up quickly and see how major components work together. Rails automatically creates much of the scaffolding you'll need.<br>
<b>Built-in testing:</b> Rails creates simple automated tests you can then extend. Rails also provides supporting code called harnesses and fixtures that make test cases easier to write and run. Ruby can then execute all your automated tests with the rake utility.<br>
<b>Three environments:</b> Rails gives you three default environments: development, testing, and production. Each behaves slightly differently, making your entire software development cycle easier. For example, Rails creates a fresh copy of the Test database for each test run.

<h1>Cookbook Application</h1>
Cookbook Application is a very basic Ruby on Rails application. It is a great way to understand the nuances that ‘Ruby’ has to offer. It is built keeping in mind that the reader is new to the world of ruby and is developing his/her first Ruby on Rails application.
The motive of this wiki page is to make the reader understand how the Cookbook application was built. And on the way to building this application, user will be introduced to some key concepts like Model, Views and Controllers. At the end of this page, reader must fairly be ready to start building his/her basic Ruby on Rails application.

<h2>A simple application to start -- Cookbook application</h2>

Start a new project. While creating a new project, remember to select Rails Application option as follows

[[File:Start_application.png|frame|none|Start a new Application]]

When we create a Rails application, rails automatically help us create a brunch of files and folders as follows:

[[File:Listing_of_cookbook_application.png|frame|none|Listing_of_cookbook_application]]

We mainly use the app directory. This is where the heart of the application is stored i.e. Models, Views and controllers.

<h2>Using scaffold to create framework</h2>
Rails scaffolding is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job.<br>
In Rubymine, we can create a scaffold by right clicking on the current Project->New->Run Rails Generator ->scaffold. This will open a dialog box to create a scaffold where we can enter the name and the attributes along with their data type. Once the scaffold has been created RubyMine will generate the model, view and controller files respectively. These files do not contain any specific methods but they provide a framework which is useful for general applications. The user can modify the MVC behavior according to his application requirements. Each scaffold has create, read, update and delete methods declared in the controller class. A user can modify the behavior of the controller through these methods.
<br>

[[File:Create_Scaffold.png|frame|none|Creating a new scaffold]]<br><br>
[[File:Scaffold.png|frame|left|Scaffold]] [[File:New_Scaffold_Categories.png|frame|center|Creating scaffold for categories]]<br>

<h2>Working without scaffold</h2>

Or you don't want to create a fully standard framework with scaffold, then you can use RubyMine generate command, you can create merely model, controller and view using generate command, there are many command included in the generate that you can use, expect those MVC, you can also crate migration, assets, intergration_test and performance_test. Or you don't want to create a empty controller and writing code all yourself you can also use scaffold_controller to create controller
Here is an example. You have create the Model and everything on your own without using the scaffolding in Ruby on Rails. You create the following class:

<pre>
class Dog < ActiveRecord::Base
end
</pre>
You can add a table Dogs. by
<pre>rails g migration CreateDogs</pre>
which also a generate command

In the Cookbook application we are considering a Cookbook which contains recipes for various dishes. The recipes have been divided into different categories, for example there is a recipe for ice tea which belongs to the category of beverages. There is a relationship which is created between a recipe and a category which can be expressed as an ice tea belongs to beverages. We can have many such recipes belonging to a single category, in this case many to one relationship is established.

<h1>Controllers for Cookbook Application</h1>
The Cookbook application starts by entering a URL in the browser which sends the request to the web server. Since our web server supports Rails application, it will hand over the control to a Rails controller.
A controller ‘controls’ the entire application by responding to the incoming requests as needed. For example, consider the following URL http ://localhost:3000/categories/show which is decoded by the controller to know that its action named show has been invoked.
All the controllers inherit only the ApplicationController which in turn inherits the ActionController::Base class. ActionContoller module provides the basic support for the controllers in Rails.
In our Cookbook application we generate Categories controller using the scaffold mechanism which populates the controller with the basic methods such as index, create, show, new, edit, update and destroy.
A simple example of index method is as follows:
<pre>
def index
@categories = Category.all

respond_to do |format|
format.html # index.html.erb
format.json { render json: @categories }
end
end

</pre>
In ruby, @ operator is used to declare instance variables. The index method makes use of @categories instance variable which is populated with all the records in the Category table. The respond_to method is used for responding to particular type of request. It contains a block and a variable |format| which determines whether the incoming request should be responded with HTML (when we are interacting with a user) or JSON format (if we are returning an object).
After executing the code, the controller will render a template of the same name. (For this example, the template is views/categories/index.html.erb).
Similarly the show method is defined as follows:
<pre>
def show
@category = Category.find(params[:id])

respond_to do |format|
format.html # show.html.erb
format.json { render json: @category }
end
end

</pre>
The show method is used to display a particular object. The show method needs to access database to search for the given object. This is done using the find method which takes params[:id] as argument. The params[:id] contains the id or primary key of the object which is passed as a parameter to look up in the database and the result is stored in the instance variable. The result is displayed by rendering the show.html.erb file.<br><br>
<b>Active Record</b><br>
In ruby, a program deals with objects which are mapped into database relational databases. This kind of mapping is facilitated by the Active Record.<br>Active Record maps the Rails classes in to database tables and rails objects into database records.
This makes it easy to perform actions on database tables by invoking the class methods. Another benefit of Active Record is database migration. Migrations can manage the evolution of a schema used by several physical databases. It’s a solution to the common problem of adding a field to make a new feature work in your local database, but being unsure of how to push that change to other developers and to the production server. With migrations, you can describe the transformations in self-contained classes that can be checked into version control systems and executed against another database that might be one, two, or five versions behind.You can find a lot more details about rails migration here[8].
<p>
<b>Method Pairs</b>
<br>There are couple of method pairs such as new-create and edit-update which are executed in sequence. In method pair one method is responsible for display preparation and the other method validates the data and attempts it to save in the database.
<pre>
def new
@category = Category.new

respond_to do |format|
format.html # new.html.erb
format.json { render json: @category }
end

end
</pre>
<pre>
def create
@category = Category.new(params[:category])

respond_to do |format|
if @category.save
format.html { redirect_to @category, notice: 'Category was successfully created.' }
format.json { render json: @category, status: :created, location: @category }
else
format.html { render action: "new" }
format.json { render json: @category.errors, status: :unprocessable_entity }
end
end
end

</pre>

The new and create methods are known as method pairs which execute in sequence. The new method is used to instantiate a new Category object whereas create method is used to successfully save the object to the database. After execution of the new method, the controller renders the new.html.erb file which displays a form to create a new Category object. The user enters the required information in the form and the object id is returned in the URL on submitting the form. Consider the following URL is generated on submitting the form: http: //localhost:3000/categories/3.
This means that Category object with id =3 will be created. The details of the object will be processed by the create method.
The controller invokes the create method to store the object in the database. An observation can be made about the @category variable in the create method.
<pre>
@category = Category.new(params[:category])
</pre>
The parameters passed in the URL after creating a new object is stored in the params hash (denoted by params[]). In this case the params[] contains an object with category_id = 3. The params[] assigns the data of object with category_id =3 to the instance variable. The data entered in the instance variable is validated using the @category.save method. If no errors are found then the object stored in the database and a message on successful creation of the object is displayed to the user. However, if the data entered in the object contains an error, the user is redirected to the new.html.erb page to resubmit the information and the errors are displayed.
Another example of such method pair is the edit and update methods. The edit method displays the table entry for an existing object, while the update method is invoked when the changes have been submitted.
</p>
<p>
<h1>Models of Cookbook Application</h1>
Model handles the data processing in a web application. Actions interact with the model to manipulate the data. Rails is capable of handling databases and this is facilitated by the model. You can base models on the Rails ActiveRecord module which contains support databases.
In our Cookbook application we have two models namely: Category and Recipe. They are represented by files category.rb and recipe.rb and each file is used to describe the relation between two classes. Let’s take a look at the two models
<br><b> category.rb</b>
<pre>
class Category < ActiveRecord::Base
has_many :recipes
end
</pre>
<br>
<b>recipe.rb</b>
<pre>class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>
</p>
<br>
*<b>Relationships in models</b>
<ul>one-to-one<br>
<pre>
class Syllabus < ActiveRecord::Base
belongs_to :course¬
end

class Course < ActiveRecord::Base
has_one :syllabus
end
</pre>
</ul><br>
<ul>many-many<br>
<pre>
class Student < ActiveRecord::Base
has_and_belongs_to_many :courses
end

class Course < ActiveRecord::Base
has_and_belongs_to_many :students
end
</pre></ul>

<br>
In Cookbook, we have many-one relationship between recipes and categories.
<p>
<h1>Views of Cookbook application</h1>
What is V in MVC? ‘V’ refers to views. Views are the actual interface that users can see. It is through views, that a user may request some data to be viewed or submits some data for processing.<br>
Views in rails are of the form file_name.html.erb. Here erb means embedded ruby. What html.erb denotes is some ruby code is embedded in HTML code. Like HTML, embedded ruby also uses tags to represent data. However, to distinguish it from the HTML code, ruby is embedded between <% %> if some non-assignment ruby operation is to be performed. If something needs to be displayed on screen, <%= %> is used.
Views are present in “app/views” folder in the rails application.
<br>
Name of the view files is same as the name of their respective controller. For e.g.:- if I have a controller movie with an action new, the corresponding view page will be new.html.erb in the app/views/movie directory.<br>
The Cookbook application views are as follows:

<b> Recipe Controller Views</b><br>
1. index.html.erb
<pre><nowiki><h1>Listing categories</h1>

<table>
<tr>
<th>Name</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @categories.each do |category| %>
<tr>
<td><%= category.name %></td>
<td><%= link_to 'Show', category %></td>
<td><%= link_to 'Edit', edit_category_path(category) %></td>
<td><%= link_to 'Destroy', category, method: :delete, data: { confirm: 'Are you sure?' } %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New Category', new_category_path %>
</nowiki></pre>

*<b><% @recipes.each do |recipe| %> </b>
Here @recipes is an instance variable of model recipe defined in index action of the controller ‘recipes’. It contains all the recipes currently present in our application. Then each recipe is taken from this instance variable and is assigned to the local variable recipe. All the subsequent lines display the recipe details (name, description and instruction).
<br>
*<b><%= link_to ‘Show’, recipe %> </b>
link_to is an ruby operator which is used to redirect the control to some other page. ‘Show’ is displayed as it is on the page and is an hyperlink. It links to a page pointed by recipe. The path is defined in the routes.rb file.
<br><br>
2. _form.html.erb
<br>
This is a partial. Partials are devices used for breaking the code in smaller, more manageable chunks. This helps in modularity and also maintain DRY principle[4]. With a partial, code for rendering a particular response is moved to its own file. So for e.g. we can use this same partial for creating and editing information, because the information involved is essentially the same.
<pre>
<%= form_for(@recipe) do |f| %>
<% if @recipe.errors.any? %>
<div id="error_explanation">
<h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>

<ul>
<% @recipe.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>

<div class="field">
<%= f.label :name %><br />
<%= f.text_field :name %>
</div>
<%= f.label :category %>
<%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %>
<div class="field">
<%= f.label :description %><br />
<%= f.text_field :description %>
</div>
<div class="field">
<%= f.label :instructions %><br />
<%= f.text_area :instructions %>
<%= f.submit %>
</div>
<% end %>
</pre>

* <b><%= form_for(@recipe) do |f| %></b>
This statement means to render a form for the instance variable @recipe.
If this page is being used for creating a new recipe, then the values for each key in the @recipe hash will be empty. If it is used for editing a recipe, @recipe will contain information corresponding to the recipe being edited.

*<b><% if @recipe.errors.any? %></b>
While saving an recipe or updating a recipe in the database, some violations may occur. Like the recipe name is left empty or its description is empty and so on. So while saving this information, database will signal some error. The errors are sent back to this page and are caught in @recipe.errors.any? statement.

*<b><%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %></b>
This statement creates a dropdown box.<br>
<ul>‘recipe’ : refers to the object to which the selected value is to be assigned. In this case , it is the recipe object</ul>
<ul>‘category_id’ : create a ‘category_id’ key in the recipe hash.</ul>
<ul>Category.all.collect {|c| [c[:name],c[:id]]} : recover all categories from the database and list them in the dropdown box. The value for each name is c[:id]. Whenever a category is selected by the user, its corresponding id is assigned to the ‘category_id’ key in the ‘recipe’ object.</ul>
<br><br>
3. new.html.erb<br>
This page is used to create a new recipe. This page simply renders the partial described above.
<pre>
<h1>New recipe</h1>
<%= render 'form' %>
<%= link_to 'Back', recipes_path %>
</pre>
*<b><%= render ‘form’ %> </b>
This statement renders the partial.
<br><br>
4. edit.html.erb
This page is used to edit a existing recipe. This page also renders the partial.
<pre>
<h1>Editing recipe</h1>
<%= render 'form' %>
<%= link_to 'Show', @recipe %> |
<%= link_to 'Back', recipes_path %>
</pre>
5. show.html.erb
This page is used to show a particular recipe requested by the user. The recipe requested is captured by the controller in the @recipe instance variable and is passed to this view.
<pre>
<p id="notice"><%= notice %></p>
<p>
<b>Name:</b>
<%= @recipe.name %>
</p>
<p>
<b>Description:</b>
<%= @recipe.description %>
</p>
<p>
<b>Instructions:</b>
<%= @recipe.instructions %>
</p>
<%= link_to 'Edit', edit_recipe_path(@recipe) %> |
<%= link_to 'Back', recipes_path %>
</pre>
<br>
<b>The Category Views are very similar to the recipe Views and can be created similarly.</b>

<h1>Conclusion</h1>

MVC was first proposed by Trygve Reenskaug in 1979. He broke applications into three types of components: models, which is responsible for maintaining the state of the application; views, which are responsible for generating a user interface; and controllers, which orchestrate the applications by receiving events from outside world, interact with model, and display an appropriate view to user. This separation of concerns led to far less computing, and in turn made the code easier to write and maintain.<br>
Use Ruby on Rails can implement MVC to build various types of web applications. The Cookbook is an easy starter. Readers can learn the basics of Ruby on Rails from this page.

<h1>References</h1>
*[1] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
*[2] http://en.wikipedia.org/wiki/Ruby_on_Rails
*[3] Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
*[4] http://en.wikipedia.org/wiki/Don't_repeat_yourself
*[5] http://guides.rubyonrails.org/getting_started.html
*[6] http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
*[7] http://en.wikipedia.org/wiki/Metaprogramming
*[8] http://net.tutsplus.com/tutorials/other/mvc-for-noobs/
<br><br>
The old wiki can be found here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4d_ch.

CSC/ECE 517 Fall 2012/ch1b 1w38

2012-10-04T01:27:52Z

Nmsarda:

<h1>Introduction</h1>
This page is aimed at asserting the importance of Model View Controller Architecture and how MVC is implemented in Cookbook application.

<h2>Model View Controller (MVC) Architecture</h2>

The purpose of creating MVC architecture is to have clear separation between the responsibilities of business logic and representation. In a nutshell the responsibilities are mentioned as below:

[[File:MVC.png|frame|none|MVC Responsibilities[8]]]

Model-View-Controller (MVC)[1] is an architectural pattern used in software engineering.In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface.<br>
The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. Having described the responsibilities of three components let’s take a look how these components interact with each other.

[[File:MVC_architecture.PNG|frame|none|MVC Architecture]]

<h2>Ruby on Rails</h2>

Ruby on Rails[2] is an MVC framework. Rails enforces a structure for application, it helps to knits the models, views, and controllers as separate chunks of functionality while the program executes. No more external configuration needed. Rails is packed with features that make you more productive, with many of the following features building on one other.<br>
<b>Metaprogramming[7]:</b> Other frameworks use extensive code generation from scratch. Metaprogramming[9] techniques use programs to write programs. Ruby is one of the best languages for metaprogramming, and Rails uses this capability well. Rails also uses code generation but relies much more on metaprogramming for the heavy lifting.<br>
<b>Active Record:</b> Rails introduces the Active Record[6] framework, which saves objects to the database. The Rails version of Active Record discovers the columns in a database schema and automatically attaches them to your domain objects using metaprogramming.<br>
<b>Convention over configuration:</b> Most web development frameworks for .NET or Java force you to write pages of configuration code. If you follow suggested naming conventions, Rails doesn't need much configuration.<br>
<b>Scaffolding:</b> You often create temporary code in the early stages of development to help get an application up quickly and see how major components work together. Rails automatically creates much of the scaffolding you'll need.<br>
<b>Built-in testing:</b> Rails creates simple automated tests you can then extend. Rails also provides supporting code called harnesses and fixtures that make test cases easier to write and run. Ruby can then execute all your automated tests with the rake utility.<br>
<b>Three environments:</b> Rails gives you three default environments: development, testing, and production. Each behaves slightly differently, making your entire software development cycle easier. For example, Rails creates a fresh copy of the Test database for each test run.

<h1>Cookbook Application</h1>
Cookbook Application is a very basic Ruby on Rails application. It is a great way to understand the nuances that ‘Ruby’ has to offer. It is built keeping in mind that the reader is new to the world of ruby and is developing his/her first Ruby on Rails application.
The motive of this wiki page is to make the reader understand how the Cookbook application was built. And on the way to building this application, user will be introduced to some key concepts like Model, Views and Controllers. At the end of this page, reader must fairly be ready to start building his/her basic Ruby on Rails application.

<h2>A simple application to start -- Cookbook application</h2>

Start a new project. While creating a new project, remember to select Rails Application option as follows

[[File:Start_application.png|frame|none|Start a new Application]]

When we create a Rails application, rails automatically help us create a brunch of files and folders as follows:

[[File:Listing_of_cookbook_application.png|frame|none|Listing_of_cookbook_application]]

We mainly use the app directory. This is where the heart of the application is stored i.e. Models, Views and controllers.

<h2>Using scaffold to create framework</h2>
Rails scaffolding is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job.<br>
In Rubymine, we can create a scaffold by right clicking on the current Project->New->Run Rails Generator ->scaffold. This will open a dialog box to create a scaffold where we can enter the name and the attributes along with their data type. Once the scaffold has been created RubyMine will generate the model, view and controller files respectively. These files do not contain any specific methods but they provide a framework which is useful for general applications. The user can modify the MVC behavior according to his application requirements. Each scaffold has create, read, update and delete methods declared in the controller class. A user can modify the behavior of the controller through these methods.
<br>

[[File:Create_Scaffold.png|frame|none|Creating a new scaffold]]<br><br>
[[File:Scaffold.png|frame|left|Scaffold]] [[File:New_Scaffold_Categories.png|frame|center|Creating scaffold for categories]]<br>

<h2>Working without scaffold</h2>

Or you don't want to create a fully standard framework with scaffold, then you can use RubyMine generate command, you can create merely model, controller and view using generate command, there are many command included in the generate that you can use, expect those MVC, you can also crate migration, assets, intergration_test and performance_test. Or you don't want to create a empty controller and writing code all yourself you can also use scaffold_controller to create controller
Here is an example. You have create the Model and everything on your own without using the scaffolding in Ruby on Rails. You create the following class:

<pre>
class Dog < ActiveRecord::Base
end
</pre>
You can add a table Dogs. by
<pre>rails g migration CreateDogs</pre>
which also a generate command

In the Cookbook application we are considering a Cookbook which contains recipes for various dishes. The recipes have been divided into different categories, for example there is a recipe for ice tea which belongs to the category of beverages. There is a relationship which is created between a recipe and a category which can be expressed as an ice tea belongs to beverages. We can have many such recipes belonging to a single category, in this case many to one relationship is established.

<h1>Controllers for Cookbook Application</h1>
The Cookbook application starts by entering a URL in the browser which sends the request to the web server. Since our web server supports Rails application, it will hand over the control to a Rails controller.
A controller ‘controls’ the entire application by responding to the incoming requests as needed. For example, consider the following URL http ://localhost:3000/categories/show which is decoded by the controller to know that its action named show has been invoked.
All the controllers inherit only the ApplicationController which in turn inherits the ActionController::Base class. ActionContoller module provides the basic support for the controllers in Rails.
In our Cookbook application we generate Categories controller using the scaffold mechanism which populates the controller with the basic methods such as index, create, show, new, edit, update and destroy.
A simple example of index method is as follows:
<pre>
def index
@categories = Category.all

respond_to do |format|
format.html # index.html.erb
format.json { render json: @categories }
end
end

</pre>
In ruby, @ operator is used to declare instance variables. The index method makes use of @categories instance variable which is populated with all the records in the Category table. The respond_to method is used for responding to particular type of request. It contains a block and a variable |format| which determines whether the incoming request should be responded with HTML (when we are interacting with a user) or JSON format (if we are returning an object).
After executing the code, the controller will render a template of the same name. (For this example, the template is views/categories/index.html.erb).
Similarly the show method is defined as follows:
<pre>
def show
@category = Category.find(params[:id])

respond_to do |format|
format.html # show.html.erb
format.json { render json: @category }
end
end

</pre>
The show method is used to display a particular object. The show method needs to access database to search for the given object. This is done using the find method which takes params[:id] as argument. The params[:id] contains the id or primary key of the object which is passed as a parameter to look up in the database and the result is stored in the instance variable. The result is displayed by rendering the show.html.erb file.<br><br>
<b>Active Record</b><br>
In ruby, a program deals with objects which are mapped into database relational databases. This kind of mapping is facilitated by the Active Record.<br>Active Record maps the Rails classes in to database tables and rails objects into database records.
This makes it easy to perform actions on database tables by invoking the class methods. Another benefit of Active Record is database migration. Migrations can manage the evolution of a schema used by several physical databases. It’s a solution to the common problem of adding a field to make a new feature work in your local database, but being unsure of how to push that change to other developers and to the production server. With migrations, you can describe the transformations in self-contained classes that can be checked into version control systems and executed against another database that might be one, two, or five versions behind.You can find a lot more details about rails migration here[8].
<p>
<b>Method Pairs</b>
<br>There are couple of method pairs such as new-create and edit-update which are executed in sequence. In method pair one method is responsible for display preparation and the other method validates the data and attempts it to save in the database.
<pre>
def new
@category = Category.new

respond_to do |format|
format.html # new.html.erb
format.json { render json: @category }
end

end
</pre>
<pre>
def create
@category = Category.new(params[:category])

respond_to do |format|
if @category.save
format.html { redirect_to @category, notice: 'Category was successfully created.' }
format.json { render json: @category, status: :created, location: @category }
else
format.html { render action: "new" }
format.json { render json: @category.errors, status: :unprocessable_entity }
end
end
end

</pre>

The new and create methods are known as method pairs which execute in sequence. The new method is used to instantiate a new Category object whereas create method is used to successfully save the object to the database. After execution of the new method, the controller renders the new.html.erb file which displays a form to create a new Category object. The user enters the required information in the form and the object id is returned in the URL on submitting the form. Consider the following URL is generated on submitting the form: http: //localhost:3000/categories/3.
This means that Category object with id =3 will be created. The details of the object will be processed by the create method.
The controller invokes the create method to store the object in the database. An observation can be made about the @category variable in the create method.
<pre>
@category = Category.new(params[:category])
</pre>
The parameters passed in the URL after creating a new object is stored in the params hash (denoted by params[]). In this case the params[] contains an object with category_id = 3. The params[] assigns the data of object with category_id =3 to the instance variable. The data entered in the instance variable is validated using the @category.save method. If no errors are found then the object stored in the database and a message on successful creation of the object is displayed to the user. However, if the data entered in the object contains an error, the user is redirected to the new.html.erb page to resubmit the information and the errors are displayed.
Another example of such method pair is the edit and update methods. The edit method displays the table entry for an existing object, while the update method is invoked when the changes have been submitted.
</p>
<p>
<h1>Models of Cookbook Application</h1>
Model handles the data processing in a web application. Actions interact with the model to manipulate the data. Rails is capable of handling databases and this is facilitated by the model. You can base models on the Rails ActiveRecord module which contains support databases.
In our Cookbook application we have two models namely: Category and Recipe. They are represented by files category.rb and recipe.rb and each file is used to describe the relation between two classes. Let’s take a look at the two models
<br><b> category.rb</b>
<pre>
class Category < ActiveRecord::Base
has_many :recipes
end
</pre>
<br>
<b>recipe.rb</b>
<pre>class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>
</p>
<br>
*<b>Relationships in models</b>
<ul>one-to-one<br>
<pre>
class Syllabus < ActiveRecord::Base
belongs_to :course¬
end

class Course < ActiveRecord::Base
has_one :syllabus
end
</pre>
</ul><br>
<ul>many-many<br>
<pre>
class Student < ActiveRecord::Base
has_and_belongs_to_many :courses
end

class Course < ActiveRecord::Base
has_and_belongs_to_many :students
end
</pre></ul>

<br>
In Cookbook, we have many-one relationship between recipes and categories.
<p>
<h1>Views of Cookbook application</h1>
What is V in MVC? ‘V’ refers to views. Views are the actual interface that users can see. It is through views, that a user may request some data to be viewed or submits some data for processing.<br>
Views in rails are of the form file_name.html.erb. Here erb means embedded ruby. What html.erb denotes is some ruby code is embedded in HTML code. Like HTML, embedded ruby also uses tags to represent data. However, to distinguish it from the HTML code, ruby is embedded between <% %> if some non-assignment ruby operation is to be performed. If something needs to be displayed on screen, <%= %> is used.
Views are present in “app/views” folder in the rails application.
<br>
Name of the view files is same as the name of their respective controller. For e.g.:- if I have a controller movie with an action new, the corresponding view page will be new.html.erb in the app/views/movie directory.<br>
The Cookbook application views are as follows:

<b> Recipe Controller Views</b><br>
1. index.html.erb
<pre><nowiki><h1>Listing categories</h1>

<table>
<tr>
<th>Name</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @categories.each do |category| %>
<tr>
<td><%= category.name %></td>
<td><%= link_to 'Show', category %></td>
<td><%= link_to 'Edit', edit_category_path(category) %></td>
<td><%= link_to 'Destroy', category, method: :delete, data: { confirm: 'Are you sure?' } %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New Category', new_category_path %>
</nowiki></pre>

*<b><% @recipes.each do |recipe| %> </b>
Here @recipes is an instance variable of model recipe defined in index action of the controller ‘recipes’. It contains all the recipes currently present in our application. Then each recipe is taken from this instance variable and is assigned to the local variable recipe. All the subsequent lines display the recipe details (name, description and instruction).
<br>
*<b><%= link_to ‘Show’, recipe %> </b>
link_to is an ruby operator which is used to redirect the control to some other page. ‘Show’ is displayed as it is on the page and is an hyperlink. It links to a page pointed by recipe. The path is defined in the routes.rb file.
<br><br>
2. _form.html.erb
<br>
This is a partial. Partials are devices used for breaking the code in smaller, more manageable chunks. This helps in modularity and also maintain DRY principle[4]. With a partial, code for rendering a particular response is moved to its own file. So for e.g. we can use this same partial for creating and editing information, because the information involved is essentially the same.
<pre>
<%= form_for(@recipe) do |f| %>
<% if @recipe.errors.any? %>
<div id="error_explanation">
<h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>

<ul>
<% @recipe.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>

<div class="field">
<%= f.label :name %><br />
<%= f.text_field :name %>
</div>
<%= f.label :category %>
<%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %>
<div class="field">
<%= f.label :description %><br />
<%= f.text_field :description %>
</div>
<div class="field">
<%= f.label :instructions %><br />
<%= f.text_area :instructions %>
<%= f.submit %>
</div>
<% end %>
</pre>

* <b><%= form_for(@recipe) do |f| %></b>
This statement means to render a form for the instance variable @recipe.
If this page is being used for creating a new recipe, then the values for each key in the @recipe hash will be empty. If it is used for editing a recipe, @recipe will contain information corresponding to the recipe being edited.

*<b><% if @recipe.errors.any? %></b>
While saving an recipe or updating a recipe in the database, some violations may occur. Like the recipe name is left empty or its description is empty and so on. So while saving this information, database will signal some error. The errors are sent back to this page and are caught in @recipe.errors.any? statement.

*<b><%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %></b>
This statement creates a dropdown box.<br>
<ul>‘recipe’ : refers to the object to which the selected value is to be assigned. In this case , it is the recipe object</ul>
<ul>‘category_id’ : create a ‘category_id’ key in the recipe hash.</ul>
<ul>Category.all.collect {|c| [c[:name],c[:id]]} : recover all categories from the database and list them in the dropdown box. The value for each name is c[:id]. Whenever a category is selected by the user, its corresponding id is assigned to the ‘category_id’ key in the ‘recipe’ object.</ul>
<br><br>
3. new.html.erb<br>
This page is used to create a new recipe. This page simply renders the partial described above.
<pre>
<h1>New recipe</h1>
<%= render 'form' %>
<%= link_to 'Back', recipes_path %>
</pre>
*<b><%= render ‘form’ %> </b>
This statement renders the partial.
<br><br>
4. edit.html.erb
This page is used to edit a existing recipe. This page also renders the partial.
<pre>
<h1>Editing recipe</h1>
<%= render 'form' %>
<%= link_to 'Show', @recipe %> |
<%= link_to 'Back', recipes_path %>
</pre>
5. show.html.erb
This page is used to show a particular recipe requested by the user. The recipe requested is captured by the controller in the @recipe instance variable and is passed to this view.
<pre>
<p id="notice"><%= notice %></p>
<p>
<b>Name:</b>
<%= @recipe.name %>
</p>
<p>
<b>Description:</b>
<%= @recipe.description %>
</p>
<p>
<b>Instructions:</b>
<%= @recipe.instructions %>
</p>
<%= link_to 'Edit', edit_recipe_path(@recipe) %> |
<%= link_to 'Back', recipes_path %>
</pre>
<br>
<b>The Category Views are very similar to the recipe Views and can be created similarly.</b>

<h1>Conclusion</h1>

MVC was first proposed by Trygve Reenskaug in 1979. He broke applications into three types of components: models, which is responsible for maintaining the state of the application; views, which are responsible for generating a user interface; and controllers, which orchestrate the applications by receiving events from outside world, interact with model, and display an appropriate view to user. This separation of concerns led to far less computing, and in turn made the code easier to write and maintain.<br>
Use Ruby on Rails can implement MVC to build various types of web applications. The Cookbook is an easy starter. Readers can learn the basics of Ruby on Rails from this page.

<h1>References</h1>
*[1] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
*[2] http://en.wikipedia.org/wiki/Ruby_on_Rails
*[3] Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
*[4] http://en.wikipedia.org/wiki/Don't_repeat_yourself
*[5] http://guides.rubyonrails.org/getting_started.html
*[6] http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
*[7] http://en.wikipedia.org/wiki/Metaprogramming
*[8] http://net.tutsplus.com/tutorials/other/mvc-for-noobs/
<br><br>
The old wiki can be found here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4d_ch.

CSC/ECE 517 Fall 2012/ch1b 1w38

2012-10-04T01:10:44Z

Nmsarda:

<h1>Introduction</h1>
This page is aimed at asserting the importance of Model View Controller Architecture and how MVC is implemented in Cookbook application.

<h2>Model View Controller (MVC) Architecture</h2>

The purpose of creating MVC architecture is to have clear separation between the responsibilities of business logic and representation. In a nutshell the responsibilities are mentioned as below:

[[File:MVC.png|MVC Responsibilities]] [8]

Model-View-Controller (MVC)[1] is an architectural pattern used in software engineering.In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface.<br>
The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. Having described the responsibilities of three components let’s take a look how these components interact with each other.

[[File:MVC_architecture.PNG|MVC Architecture]]

<h2>Ruby on Rails</h2>

Ruby on Rails[2] is an MVC framework. Rails enforces a structure for application, it helps to knits the models, views, and controllers as separate chunks of functionality while the program executes. No more external configuration needed. Rails is packed with features that make you more productive, with many of the following features building on one other.<br>
<b>Metaprogramming[7]:</b> Other frameworks use extensive code generation from scratch. Metaprogramming[9] techniques use programs to write programs. Ruby is one of the best languages for metaprogramming, and Rails uses this capability well. Rails also uses code generation but relies much more on metaprogramming for the heavy lifting.<br>
<b>Active Record:</b> Rails introduces the Active Record[6] framework, which saves objects to the database. The Rails version of Active Record discovers the columns in a database schema and automatically attaches them to your domain objects using metaprogramming.<br>
<b>Convention over configuration:</b> Most web development frameworks for .NET or Java force you to write pages of configuration code. If you follow suggested naming conventions, Rails doesn't need much configuration.<br>
<b>Scaffolding:</b> You often create temporary code in the early stages of development to help get an application up quickly and see how major components work together. Rails automatically creates much of the scaffolding you'll need.<br>
<b>Built-in testing:</b> Rails creates simple automated tests you can then extend. Rails also provides supporting code called harnesses and fixtures that make test cases easier to write and run. Ruby can then execute all your automated tests with the rake utility.<br>
<b>Three environments:</b> Rails gives you three default environments: development, testing, and production. Each behaves slightly differently, making your entire software development cycle easier. For example, Rails creates a fresh copy of the Test database for each test run.

<h1>Cookbook Application</h1>
Cookbook Application is a very basic Ruby on Rails application. It is a great way to understand the nuances that ‘Ruby’ has to offer. It is built keeping in mind that the reader is new to the world of ruby and is developing his/her first Ruby on Rails application.
The motive of this wiki page is to make the reader understand how the Cookbook application was built. And on the way to building this application, user will be introduced to some key concepts like Model, Views and Controllers. At the end of this page, reader must fairly be ready to start building his/her basic Ruby on Rails application.

<h2>A simple application to start -- Cookbook application</h2>

Start a new project. While creating a new project, remember to select Rails Application option as follows

[[File:Start_application.png|Start a new Application]]

When we create a Rails application, rails automatically help us create a brunch of files and folders as follows:

[[File:Listing_of_cookbook_application.png|Listing_of_cookbook_application]]

We mainly use the app directory. This is where the heart of the application is stored i.e. Models, Views and controllers.

<h2>Using scaffold to create framework</h2>
Rails scaffolding is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job.<br>
In Rubymine, we can create a scaffold by right clicking on the current Project->New->Run Rails Generator ->scaffold. This will open a dialog box to create a scaffold where we can enter the name and the attributes along with their data type. Once the scaffold has been created RubyMine will generate the model, view and controller files respectively. These files do not contain any specific methods but they provide a framework which is useful for general applications. The user can modify the MVC behavior according to his application requirements. Each scaffold has create, read, update and delete methods declared in the controller class. A user can modify the behavior of the controller through these methods.
<br>

<br>[[File:Create_Scaffold.png|text-bottom|thumb|Creating a new scaffold]]<br><br>
[[File:Scaffold.png|Scaffold]] [[File:New_Scaffold_Categories.png|Creating scaffold for categories]]<br><br>

<h2>Working without scaffold</h2>

Or you don't want to create a fully standard framework with scaffold, then you can use RubyMine generate command, you can create merely model, controller and view using generate command, there are many command included in the generate that you can use, expect those MVC, you can also crate migration, assets, intergration_test and performance_test. Or you don't want to create a empty controller and writing code all yourself you can also use scaffold_controller to create controller
Here is an example. You have create the Model and everything on your own without using the scaffolding in Ruby on Rails. You create the following class:

In the Cookbook application we are considering a Cookbook which contains recipes for various dishes. The recipes have been divided into different categories, for example there is a recipe for ice tea which belongs to the category of beverages. There is a relationship which is created between a recipe and a category which can be expressed as an ice tea belongs to beverages. We can have many such recipes belonging to a single category, in this case many to one relationship is established.

<h1>Controllers for Cookbook Application</h1>
The Cookbook application starts by entering a URL in the browser which sends the request to the web server. Since our web server supports Rails application, it will hand over the control to a Rails controller.
A controller ‘controls’ the entire application by responding to the incoming requests as needed. For example, consider the following URL http ://localhost:3000/categories/show which is decoded by the controller to know that its action named show has been invoked.
All the controllers inherit only the ApplicationController which in turn inherits the ActionController::Base class. ActionContoller module provides the basic support for the controllers in Rails.
In our Cookbook application we generate Categories controller using the scaffold mechanism which populates the controller with the basic methods such as index, create, show, new, edit, update and destroy.
A simple example of index method is as follows:
<pre>
def index
@categories = Category.all

respond_to do |format|
format.html # index.html.erb
format.json { render json: @categories }
end
end

</pre>
In ruby, @ operator is used to declare instance variables. The index method makes use of @categories instance variable which is populated with all the records in the Category table. The respond_to method is used for responding to particular type of request. It contains a block and a variable |format| which determines whether the incoming request should be responded with HTML (when we are interacting with a user) or JSON format (if we are returning an object).
After executing the code, the controller will render a template of the same name. (For this example, the template is views/categories/index.html.erb).
Similarly the show method is defined as follows:
<pre>
def show
@category = Category.find(params[:id])

respond_to do |format|
format.html # show.html.erb
format.json { render json: @category }
end
end

</pre>
The show method is used to display a particular object. The show method needs to access database to search for the given object. This is done using the find method which takes params[:id] as argument. The params[:id] contains the id or primary key of the object which is passed as a parameter to look up in the database and the result is stored in the instance variable. The result is displayed by rendering the show.html.erb file.<br><br>
<b>Active Record</b><br>
In ruby, a program deals with objects which are mapped into database relational databases. This kind of mapping is facilitated by the Active Record.<br>Active Record maps the Rails classes in to database tables and rails objects into database records.
This makes it easy to perform actions on database tables by invoking the class methods. Another benefit of Active Record is database migration. Migrations can manage the evolution of a schema used by several physical databases. It’s a solution to the common problem of adding a field to make a new feature work in your local database, but being unsure of how to push that change to other developers and to the production server. With migrations, you can describe the transformations in self-contained classes that can be checked into version control systems and executed against another database that might be one, two, or five versions behind.You can find a lot more details about rails migration here[8].
<p>
<b>Method Pairs</b>
<br>There are couple of method pairs such as new-create and edit-update which are executed in sequence. In method pair one method is responsible for display preparation and the other method validates the data and attempts it to save in the database.
<pre>
def new
@category = Category.new

respond_to do |format|
format.html # new.html.erb
format.json { render json: @category }
end

end
</pre>
<pre>
def create
@category = Category.new(params[:category])

respond_to do |format|
if @category.save
format.html { redirect_to @category, notice: 'Category was successfully created.' }
format.json { render json: @category, status: :created, location: @category }
else
format.html { render action: "new" }
format.json { render json: @category.errors, status: :unprocessable_entity }
end
end
end

</pre>

The new and create methods are known as method pairs which execute in sequence. The new method is used to instantiate a new Category object whereas create method is used to successfully save the object to the database. After execution of the new method, the controller renders the new.html.erb file which displays a form to create a new Category object. The user enters the required information in the form and the object id is returned in the URL on submitting the form. Consider the following URL is generated on submitting the form: http: //localhost:3000/categories/3.
This means that Category object with id =3 will be created. The details of the object will be processed by the create method.
The controller invokes the create method to store the object in the database. An observation can be made about the @category variable in the create method.
<pre>
@category = Category.new(params[:category])
</pre>
The parameters passed in the URL after creating a new object is stored in the params hash (denoted by params[]). In this case the params[] contains an object with category_id = 3. The params[] assigns the data of object with category_id =3 to the instance variable. The data entered in the instance variable is validated using the @category.save method. If no errors are found then the object stored in the database and a message on successful creation of the object is displayed to the user. However, if the data entered in the object contains an error, the user is redirected to the new.html.erb page to resubmit the information and the errors are displayed.
Another example of such method pair is the edit and update methods. The edit method displays the table entry for an existing object, while the update method is invoked when the changes have been submitted.
</p>
<p>
<h1>Models of Cookbook Application</h1>
Model handles the data processing in a web application. Actions interact with the model to manipulate the data. Rails is capable of handling databases and this is facilitated by the model. You can base models on the Rails ActiveRecord module which contains support databases.
In our Cookbook application we have two models namely: Category and Recipe. They are represented by files category.rb and recipe.rb and each file is used to describe the relation between two classes. Let’s take a look at the two models
<br><b> category.rb</b>
<pre>
class Category < ActiveRecord::Base
has_many :recipes
end
</pre>
<br>
<b>recipe.rb</b>
<pre>class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>
</p>
<br>
*<b>Relationships in models</b>
<ul>one-to-one<br>
<pre>
class Syllabus < ActiveRecord::Base
belongs_to :course¬
end

class Course < ActiveRecord::Base
has_one :syllabus
end
</pre>
</ul><br>
<ul>many-many<br>
<pre>
class Student < ActiveRecord::Base
has_and_belongs_to_many :courses
end

class Course < ActiveRecord::Base
has_and_belongs_to_many :students
end
</pre></ul>

<br>
In Cookbook, we have many-one relationship between recipes and categories.
<p>
<h1>Views of Cookbook application</h1>
What is V in MVC? ‘V’ refers to views. Views are the actual interface that users can see. It is through views, that a user may request some data to be viewed or submits some data for processing.<br>
Views in rails are of the form file_name.html.erb. Here erb means embedded ruby. What html.erb denotes is some ruby code is embedded in HTML code. Like HTML, embedded ruby also uses tags to represent data. However, to distinguish it from the HTML code, ruby is embedded between <% %> if some non-assignment ruby operation is to be performed. If something needs to be displayed on screen, <%= %> is used.
Views are present in “app/views” folder in the rails application.
<br>
Name of the view files is same as the name of their respective controller. For e.g.:- if I have a controller movie with an action new, the corresponding view page will be new.html.erb in the app/views/movie directory.<br>
The Cookbook application views are as follows:

<b> Recipe Controller Views</b><br>
1. index.html.erb
<pre><nowiki><h1>Listing categories</h1>

<table>
<tr>
<th>Name</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @categories.each do |category| %>
<tr>
<td><%= category.name %></td>
<td><%= link_to 'Show', category %></td>
<td><%= link_to 'Edit', edit_category_path(category) %></td>
<td><%= link_to 'Destroy', category, method: :delete, data: { confirm: 'Are you sure?' } %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New Category', new_category_path %>
</nowiki></pre>

*<b><% @recipes.each do |recipe| %> </b>
Here @recipes is an instance variable of model recipe defined in index action of the controller ‘recipes’. It contains all the recipes currently present in our application. Then each recipe is taken from this instance variable and is assigned to the local variable recipe. All the subsequent lines display the recipe details (name, description and instruction).
<br>
*<b><%= link_to ‘Show’, recipe %> </b>
link_to is an ruby operator which is used to redirect the control to some other page. ‘Show’ is displayed as it is on the page and is an hyperlink. It links to a page pointed by recipe. The path is defined in the routes.rb file.
<br><br>
2. _form.html.erb
<br>
This is a partial. Partials are devices used for breaking the code in smaller, more manageable chunks. This helps in modularity and also maintain DRY principle[4]. With a partial, code for rendering a particular response is moved to its own file. So for e.g. we can use this same partial for creating and editing information, because the information involved is essentially the same.
<pre>
<%= form_for(@recipe) do |f| %>
<% if @recipe.errors.any? %>
<div id="error_explanation">
<h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>

<ul>
<% @recipe.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>

<div class="field">
<%= f.label :name %><br />
<%= f.text_field :name %>
</div>
<%= f.label :category %>
<%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %>
<div class="field">
<%= f.label :description %><br />
<%= f.text_field :description %>
</div>
<div class="field">
<%= f.label :instructions %><br />
<%= f.text_area :instructions %>
<%= f.submit %>
</div>
<% end %>
</pre>

* <b><%= form_for(@recipe) do |f| %></b>
This statement means to render a form for the instance variable @recipe.
If this page is being used for creating a new recipe, then the values for each key in the @recipe hash will be empty. If it is used for editing a recipe, @recipe will contain information corresponding to the recipe being edited.

*<b><% if @recipe.errors.any? %></b>
While saving an recipe or updating a recipe in the database, some violations may occur. Like the recipe name is left empty or its description is empty and so on. So while saving this information, database will signal some error. The errors are sent back to this page and are caught in @recipe.errors.any? statement.

*<b><%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %></b>
This statement creates a dropdown box.<br>
<ul>‘recipe’ : refers to the object to which the selected value is to be assigned. In this case , it is the recipe object</ul>
<ul>‘category_id’ : create a ‘category_id’ key in the recipe hash.</ul>
<ul>Category.all.collect {|c| [c[:name],c[:id]]} : recover all categories from the database and list them in the dropdown box. The value for each name is c[:id]. Whenever a category is selected by the user, its corresponding id is assigned to the ‘category_id’ key in the ‘recipe’ object.</ul>
<br><br>
3. new.html.erb<br>
This page is used to create a new recipe. This page simply renders the partial described above.
<pre>
<h1>New recipe</h1>
<%= render 'form' %>
<%= link_to 'Back', recipes_path %>
</pre>
*<b><%= render ‘form’ %> </b>
This statement renders the partial.
<br><br>
4. edit.html.erb
This page is used to edit a existing recipe. This page also renders the partial.
<pre>
<h1>Editing recipe</h1>
<%= render 'form' %>
<%= link_to 'Show', @recipe %> |
<%= link_to 'Back', recipes_path %>
</pre>
5. show.html.erb
This page is used to show a particular recipe requested by the user. The recipe requested is captured by the controller in the @recipe instance variable and is passed to this view.
<pre>
<p id="notice"><%= notice %></p>
<p>
<b>Name:</b>
<%= @recipe.name %>
</p>
<p>
<b>Description:</b>
<%= @recipe.description %>
</p>
<p>
<b>Instructions:</b>
<%= @recipe.instructions %>
</p>
<%= link_to 'Edit', edit_recipe_path(@recipe) %> |
<%= link_to 'Back', recipes_path %>
</pre>
<br>
<b>The Category Views are very similar to the recipe Views and can be created similarly.</b>

<h1>Conclusion</h1>

MVC was first proposed by Trygve Reenskaug in 1979. He broke applications into three types of components: models, which is responsible for maintaining the state of the application; views, which are responsible for generating a user interface; and controllers, which orchestrate the applications by receiving events from outside world, interact with model, and display an appropriate view to user. This separation of concerns led to far less computing, and in turn made the code easier to write and maintain.<br>
Use Ruby on Rails can implement MVC to build various types of web applications. The Cookbook is an easy starter. Readers can learn the basics of Ruby on Rails from this page.

<h1>References</h1>
*[1] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
*[2] http://en.wikipedia.org/wiki/Ruby_on_Rails
*[3] Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
*[4] http://en.wikipedia.org/wiki/Don't_repeat_yourself
*[5] http://guides.rubyonrails.org/getting_started.html
*[6] http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
*[7] http://en.wikipedia.org/wiki/Metaprogramming
*[8] http://net.tutsplus.com/tutorials/other/mvc-for-noobs/
<br><br>
The old wiki can be found here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4d_ch.

CSC/ECE 517 Fall 2012/ch1b 1w38

2012-10-04T01:09:40Z

Nmsarda:

<h1>Introduction</h1>
This page is aimed at asserting the importance of Model View Controller Architecture and how MVC is implemented in Cookbook application.

<h2>Model View Controller (MVC) Architecture</h2>

The purpose of creating MVC architecture is to have clear separation between the responsibilities of business logic and representation. In a nutshell the responsibilities are mentioned as below:

[[File:MVC.png|MVC Responsibilities]] [8]

Model-View-Controller (MVC)[1] is an architectural pattern used in software engineering.In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface.<br>
The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. Having described the responsibilities of three components let’s take a look how these components interact with each other.

[[File:MVC_architecture.PNG|MVC Architecture]]

<h2>Ruby on Rails</h2>

Ruby on Rails[2] is an MVC framework. Rails enforces a structure for application, it helps to knits the models, views, and controllers as separate chunks of functionality while the program executes. No more external configuration needed. Rails is packed with features that make you more productive, with many of the following features building on one other.<br>
<b>Metaprogramming[7]:</b> Other frameworks use extensive code generation from scratch. Metaprogramming[9] techniques use programs to write programs. Ruby is one of the best languages for metaprogramming, and Rails uses this capability well. Rails also uses code generation but relies much more on metaprogramming for the heavy lifting.<br>
<b>Active Record:</b> Rails introduces the Active Record[6] framework, which saves objects to the database. The Rails version of Active Record discovers the columns in a database schema and automatically attaches them to your domain objects using metaprogramming.<br>
<b>Convention over configuration:</b> Most web development frameworks for .NET or Java force you to write pages of configuration code. If you follow suggested naming conventions, Rails doesn't need much configuration.<br>
<b>Scaffolding:</b> You often create temporary code in the early stages of development to help get an application up quickly and see how major components work together. Rails automatically creates much of the scaffolding you'll need.<br>
<b>Built-in testing:</b> Rails creates simple automated tests you can then extend. Rails also provides supporting code called harnesses and fixtures that make test cases easier to write and run. Ruby can then execute all your automated tests with the rake utility.<br>
<b>Three environments:</b> Rails gives you three default environments: development, testing, and production. Each behaves slightly differently, making your entire software development cycle easier. For example, Rails creates a fresh copy of the Test database for each test run.

<h1>Cookbook Application</h1>
Cookbook Application is a very basic Ruby on Rails application. It is a great way to understand the nuances that ‘Ruby’ has to offer. It is built keeping in mind that the reader is new to the world of ruby and is developing his/her first Ruby on Rails application.
The motive of this wiki page is to make the reader understand how the Cookbook application was built. And on the way to building this application, user will be introduced to some key concepts like Model, Views and Controllers. At the end of this page, reader must fairly be ready to start building his/her basic Ruby on Rails application.

<h2>A simple application to start -- Cookbook application</h2>

Start a new project. While creating a new project, remember to select Rails Application option as follows

[[File:Start_application.png|Start a new Application]]

When we create a Rails application, rails automatically help us create a brunch of files and folders as follows:

[[File:Listing_of_cookbook_application.png|Listing_of_cookbook_application]]

We mainly use the app directory. This is where the heart of the application is stored i.e. Models, Views and controllers.

<h2>Using scaffold to create framework</h2>
Rails scaffolding is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job.<br>
In Rubymine, we can create a scaffold by right clicking on the current Project->New->Run Rails Generator ->scaffold. This will open a dialog box to create a scaffold where we can enter the name and the attributes along with their data type. Once the scaffold has been created RubyMine will generate the model, view and controller files respectively. These files do not contain any specific methods but they provide a framework which is useful for general applications. The user can modify the MVC behavior according to his application requirements. Each scaffold has create, read, update and delete methods declared in the controller class. A user can modify the behavior of the controller through these methods.
<br>

<br>[[File:Create_Scaffold.png|thumb|Creating a new scaffold]]<br><br>
[[File:Scaffold.png|Scaffold]] [[File:New_Scaffold_Categories.png|Creating scaffold for categories]]<br><br>

<h2>Working without scaffold</h2>

Or you don't want to create a fully standard framework with scaffold, then you can use RubyMine generate command, you can create merely model, controller and view using generate command, there are many command included in the generate that you can use, expect those MVC, you can also crate migration, assets, intergration_test and performance_test. Or you don't want to create a empty controller and writing code all yourself you can also use scaffold_controller to create controller
Here is an example. You have create the Model and everything on your own without using the scaffolding in Ruby on Rails. You create the following class:

In the Cookbook application we are considering a Cookbook which contains recipes for various dishes. The recipes have been divided into different categories, for example there is a recipe for ice tea which belongs to the category of beverages. There is a relationship which is created between a recipe and a category which can be expressed as an ice tea belongs to beverages. We can have many such recipes belonging to a single category, in this case many to one relationship is established.

<h1>Controllers for Cookbook Application</h1>
The Cookbook application starts by entering a URL in the browser which sends the request to the web server. Since our web server supports Rails application, it will hand over the control to a Rails controller.
A controller ‘controls’ the entire application by responding to the incoming requests as needed. For example, consider the following URL http ://localhost:3000/categories/show which is decoded by the controller to know that its action named show has been invoked.
All the controllers inherit only the ApplicationController which in turn inherits the ActionController::Base class. ActionContoller module provides the basic support for the controllers in Rails.
In our Cookbook application we generate Categories controller using the scaffold mechanism which populates the controller with the basic methods such as index, create, show, new, edit, update and destroy.
A simple example of index method is as follows:
<pre>
def index
@categories = Category.all

respond_to do |format|
format.html # index.html.erb
format.json { render json: @categories }
end
end

</pre>
In ruby, @ operator is used to declare instance variables. The index method makes use of @categories instance variable which is populated with all the records in the Category table. The respond_to method is used for responding to particular type of request. It contains a block and a variable |format| which determines whether the incoming request should be responded with HTML (when we are interacting with a user) or JSON format (if we are returning an object).
After executing the code, the controller will render a template of the same name. (For this example, the template is views/categories/index.html.erb).
Similarly the show method is defined as follows:
<pre>
def show
@category = Category.find(params[:id])

respond_to do |format|
format.html # show.html.erb
format.json { render json: @category }
end
end

</pre>
The show method is used to display a particular object. The show method needs to access database to search for the given object. This is done using the find method which takes params[:id] as argument. The params[:id] contains the id or primary key of the object which is passed as a parameter to look up in the database and the result is stored in the instance variable. The result is displayed by rendering the show.html.erb file.<br><br>
<b>Active Record</b><br>
In ruby, a program deals with objects which are mapped into database relational databases. This kind of mapping is facilitated by the Active Record.<br>Active Record maps the Rails classes in to database tables and rails objects into database records.
This makes it easy to perform actions on database tables by invoking the class methods. Another benefit of Active Record is database migration. Migrations can manage the evolution of a schema used by several physical databases. It’s a solution to the common problem of adding a field to make a new feature work in your local database, but being unsure of how to push that change to other developers and to the production server. With migrations, you can describe the transformations in self-contained classes that can be checked into version control systems and executed against another database that might be one, two, or five versions behind.You can find a lot more details about rails migration here[8].
<p>
<b>Method Pairs</b>
<br>There are couple of method pairs such as new-create and edit-update which are executed in sequence. In method pair one method is responsible for display preparation and the other method validates the data and attempts it to save in the database.
<pre>
def new
@category = Category.new

respond_to do |format|
format.html # new.html.erb
format.json { render json: @category }
end

end
</pre>
<pre>
def create
@category = Category.new(params[:category])

respond_to do |format|
if @category.save
format.html { redirect_to @category, notice: 'Category was successfully created.' }
format.json { render json: @category, status: :created, location: @category }
else
format.html { render action: "new" }
format.json { render json: @category.errors, status: :unprocessable_entity }
end
end
end

</pre>

The new and create methods are known as method pairs which execute in sequence. The new method is used to instantiate a new Category object whereas create method is used to successfully save the object to the database. After execution of the new method, the controller renders the new.html.erb file which displays a form to create a new Category object. The user enters the required information in the form and the object id is returned in the URL on submitting the form. Consider the following URL is generated on submitting the form: http: //localhost:3000/categories/3.
This means that Category object with id =3 will be created. The details of the object will be processed by the create method.
The controller invokes the create method to store the object in the database. An observation can be made about the @category variable in the create method.
<pre>
@category = Category.new(params[:category])
</pre>
The parameters passed in the URL after creating a new object is stored in the params hash (denoted by params[]). In this case the params[] contains an object with category_id = 3. The params[] assigns the data of object with category_id =3 to the instance variable. The data entered in the instance variable is validated using the @category.save method. If no errors are found then the object stored in the database and a message on successful creation of the object is displayed to the user. However, if the data entered in the object contains an error, the user is redirected to the new.html.erb page to resubmit the information and the errors are displayed.
Another example of such method pair is the edit and update methods. The edit method displays the table entry for an existing object, while the update method is invoked when the changes have been submitted.
</p>
<p>
<h1>Models of Cookbook Application</h1>
Model handles the data processing in a web application. Actions interact with the model to manipulate the data. Rails is capable of handling databases and this is facilitated by the model. You can base models on the Rails ActiveRecord module which contains support databases.
In our Cookbook application we have two models namely: Category and Recipe. They are represented by files category.rb and recipe.rb and each file is used to describe the relation between two classes. Let’s take a look at the two models
<br><b> category.rb</b>
<pre>
class Category < ActiveRecord::Base
has_many :recipes
end
</pre>
<br>
<b>recipe.rb</b>
<pre>class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>
</p>
<br>
*<b>Relationships in models</b>
<ul>one-to-one<br>
<pre>
class Syllabus < ActiveRecord::Base
belongs_to :course¬
end

class Course < ActiveRecord::Base
has_one :syllabus
end
</pre>
</ul><br>
<ul>many-many<br>
<pre>
class Student < ActiveRecord::Base
has_and_belongs_to_many :courses
end

class Course < ActiveRecord::Base
has_and_belongs_to_many :students
end
</pre></ul>

<br>
In Cookbook, we have many-one relationship between recipes and categories.
<p>
<h1>Views of Cookbook application</h1>
What is V in MVC? ‘V’ refers to views. Views are the actual interface that users can see. It is through views, that a user may request some data to be viewed or submits some data for processing.<br>
Views in rails are of the form file_name.html.erb. Here erb means embedded ruby. What html.erb denotes is some ruby code is embedded in HTML code. Like HTML, embedded ruby also uses tags to represent data. However, to distinguish it from the HTML code, ruby is embedded between <% %> if some non-assignment ruby operation is to be performed. If something needs to be displayed on screen, <%= %> is used.
Views are present in “app/views” folder in the rails application.
<br>
Name of the view files is same as the name of their respective controller. For e.g.:- if I have a controller movie with an action new, the corresponding view page will be new.html.erb in the app/views/movie directory.<br>
The Cookbook application views are as follows:

<b> Recipe Controller Views</b><br>
1. index.html.erb
<pre><nowiki><h1>Listing categories</h1>

<table>
<tr>
<th>Name</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @categories.each do |category| %>
<tr>
<td><%= category.name %></td>
<td><%= link_to 'Show', category %></td>
<td><%= link_to 'Edit', edit_category_path(category) %></td>
<td><%= link_to 'Destroy', category, method: :delete, data: { confirm: 'Are you sure?' } %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New Category', new_category_path %>
</nowiki></pre>

*<b><% @recipes.each do |recipe| %> </b>
Here @recipes is an instance variable of model recipe defined in index action of the controller ‘recipes’. It contains all the recipes currently present in our application. Then each recipe is taken from this instance variable and is assigned to the local variable recipe. All the subsequent lines display the recipe details (name, description and instruction).
<br>
*<b><%= link_to ‘Show’, recipe %> </b>
link_to is an ruby operator which is used to redirect the control to some other page. ‘Show’ is displayed as it is on the page and is an hyperlink. It links to a page pointed by recipe. The path is defined in the routes.rb file.
<br><br>
2. _form.html.erb
<br>
This is a partial. Partials are devices used for breaking the code in smaller, more manageable chunks. This helps in modularity and also maintain DRY principle[4]. With a partial, code for rendering a particular response is moved to its own file. So for e.g. we can use this same partial for creating and editing information, because the information involved is essentially the same.
<pre>
<%= form_for(@recipe) do |f| %>
<% if @recipe.errors.any? %>
<div id="error_explanation">
<h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>

<ul>
<% @recipe.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>

<div class="field">
<%= f.label :name %><br />
<%= f.text_field :name %>
</div>
<%= f.label :category %>
<%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %>
<div class="field">
<%= f.label :description %><br />
<%= f.text_field :description %>
</div>
<div class="field">
<%= f.label :instructions %><br />
<%= f.text_area :instructions %>
<%= f.submit %>
</div>
<% end %>
</pre>

* <b><%= form_for(@recipe) do |f| %></b>
This statement means to render a form for the instance variable @recipe.
If this page is being used for creating a new recipe, then the values for each key in the @recipe hash will be empty. If it is used for editing a recipe, @recipe will contain information corresponding to the recipe being edited.

*<b><% if @recipe.errors.any? %></b>
While saving an recipe or updating a recipe in the database, some violations may occur. Like the recipe name is left empty or its description is empty and so on. So while saving this information, database will signal some error. The errors are sent back to this page and are caught in @recipe.errors.any? statement.

*<b><%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %></b>
This statement creates a dropdown box.<br>
<ul>‘recipe’ : refers to the object to which the selected value is to be assigned. In this case , it is the recipe object</ul>
<ul>‘category_id’ : create a ‘category_id’ key in the recipe hash.</ul>
<ul>Category.all.collect {|c| [c[:name],c[:id]]} : recover all categories from the database and list them in the dropdown box. The value for each name is c[:id]. Whenever a category is selected by the user, its corresponding id is assigned to the ‘category_id’ key in the ‘recipe’ object.</ul>
<br><br>
3. new.html.erb<br>
This page is used to create a new recipe. This page simply renders the partial described above.
<pre>
<h1>New recipe</h1>
<%= render 'form' %>
<%= link_to 'Back', recipes_path %>
</pre>
*<b><%= render ‘form’ %> </b>
This statement renders the partial.
<br><br>
4. edit.html.erb
This page is used to edit a existing recipe. This page also renders the partial.
<pre>
<h1>Editing recipe</h1>
<%= render 'form' %>
<%= link_to 'Show', @recipe %> |
<%= link_to 'Back', recipes_path %>
</pre>
5. show.html.erb
This page is used to show a particular recipe requested by the user. The recipe requested is captured by the controller in the @recipe instance variable and is passed to this view.
<pre>
<p id="notice"><%= notice %></p>
<p>
<b>Name:</b>
<%= @recipe.name %>
</p>
<p>
<b>Description:</b>
<%= @recipe.description %>
</p>
<p>
<b>Instructions:</b>
<%= @recipe.instructions %>
</p>
<%= link_to 'Edit', edit_recipe_path(@recipe) %> |
<%= link_to 'Back', recipes_path %>
</pre>
<br>
<b>The Category Views are very similar to the recipe Views and can be created similarly.</b>

<h1>Conclusion</h1>

MVC was first proposed by Trygve Reenskaug in 1979. He broke applications into three types of components: models, which is responsible for maintaining the state of the application; views, which are responsible for generating a user interface; and controllers, which orchestrate the applications by receiving events from outside world, interact with model, and display an appropriate view to user. This separation of concerns led to far less computing, and in turn made the code easier to write and maintain.<br>
Use Ruby on Rails can implement MVC to build various types of web applications. The Cookbook is an easy starter. Readers can learn the basics of Ruby on Rails from this page.

<h1>References</h1>
*[1] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
*[2] http://en.wikipedia.org/wiki/Ruby_on_Rails
*[3] Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
*[4] http://en.wikipedia.org/wiki/Don't_repeat_yourself
*[5] http://guides.rubyonrails.org/getting_started.html
*[6] http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
*[7] http://en.wikipedia.org/wiki/Metaprogramming
*[8] http://net.tutsplus.com/tutorials/other/mvc-for-noobs/
<br><br>
The old wiki can be found here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4d_ch.

CSC/ECE 517 Fall 2012/ch1b 1w38

2012-10-04T01:04:53Z

Nmsarda:

<h1>Introduction</h1>
This page is aimed at asserting the importance of Model View Controller Architecture and how MVC is implemented in Cookbook application.

<h2>Model View Controller (MVC) Architecture</h2>

The purpose of creating MVC architecture is to have clear separation between the responsibilities of business logic and representation. In a nutshell the responsibilities are mentioned as below:

[[File:MVC.png|MVC Responsibilities]] [8]

Model-View-Controller (MVC)[1] is an architectural pattern used in software engineering.In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface.<br>
The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. Having described the responsibilities of three components let’s take a look how these components interact with each other.

[[File:MVC_architecture.PNG|MVC Architecture]]

<h2>Ruby on Rails</h2>

Ruby on Rails[2] is an MVC framework. Rails enforces a structure for application, it helps to knits the models, views, and controllers as separate chunks of functionality while the program executes. No more external configuration needed. Rails is packed with features that make you more productive, with many of the following features building on one other.<br>
<b>Metaprogramming[7]:</b> Other frameworks use extensive code generation from scratch. Metaprogramming[9] techniques use programs to write programs. Ruby is one of the best languages for metaprogramming, and Rails uses this capability well. Rails also uses code generation but relies much more on metaprogramming for the heavy lifting.<br>
<b>Active Record:</b> Rails introduces the Active Record[6] framework, which saves objects to the database. The Rails version of Active Record discovers the columns in a database schema and automatically attaches them to your domain objects using metaprogramming.<br>
<b>Convention over configuration:</b> Most web development frameworks for .NET or Java force you to write pages of configuration code. If you follow suggested naming conventions, Rails doesn't need much configuration.<br>
<b>Scaffolding:</b> You often create temporary code in the early stages of development to help get an application up quickly and see how major components work together. Rails automatically creates much of the scaffolding you'll need.<br>
<b>Built-in testing:</b> Rails creates simple automated tests you can then extend. Rails also provides supporting code called harnesses and fixtures that make test cases easier to write and run. Ruby can then execute all your automated tests with the rake utility.<br>
<b>Three environments:</b> Rails gives you three default environments: development, testing, and production. Each behaves slightly differently, making your entire software development cycle easier. For example, Rails creates a fresh copy of the Test database for each test run.

<h1>Cookbook Application</h1>
Cookbook Application is a very basic Ruby on Rails application. It is a great way to understand the nuances that ‘Ruby’ has to offer. It is built keeping in mind that the reader is new to the world of ruby and is developing his/her first Ruby on Rails application.
The motive of this wiki page is to make the reader understand how the Cookbook application was built. And on the way to building this application, user will be introduced to some key concepts like Model, Views and Controllers. At the end of this page, reader must fairly be ready to start building his/her basic Ruby on Rails application.

<h2>A simple application to start -- Cookbook application</h2>

Start a new project. While creating a new project, remember to select Rails Application option as follows

[[File:Start_application.png|Start a new Application]]

When we create a Rails application, rails automatically help us create a brunch of files and folders as follows:

[[File:Listing_of_cookbook_application.png|Listing_of_cookbook_application]]

We mainly use the app directory. This is where the heart of the application is stored i.e. Models, Views and controllers.

<h2>Using scaffold to create framework</h2>
Rails scaffolding is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job.<br>
In Rubymine, we can create a scaffold by right clicking on the current Project->New->Run Rails Generator ->scaffold. This will open a dialog box to create a scaffold where we can enter the name and the attributes along with their data type. Once the scaffold has been created RubyMine will generate the model, view and controller files respectively. These files do not contain any specific methods but they provide a framework which is useful for general applications. The user can modify the MVC behavior according to his application requirements. Each scaffold has create, read, update and delete methods declared in the controller class. A user can modify the behavior of the controller through these methods.
<br>

<br>[[File:Create_Scaffold.png|Creating a new scaffold]]<br><br>
[[File:Scaffold.png|Scaffold]] [[File:New_Scaffold_Categories.png|Creating scaffold for categories]]<br><br>

In the Cookbook application we are considering a Cookbook which contains recipes for various dishes. The recipes have been divided into different categories, for example there is a recipe for ice tea which belongs to the category of beverages. There is a relationship which is created between a recipe and a category which can be expressed as an ice tea belongs to beverages. We can have many such recipes belonging to a single category, in this case many to one relationship is established.

<h1>Controllers for Cookbook Application</h1>
The Cookbook application starts by entering a URL in the browser which sends the request to the web server. Since our web server supports Rails application, it will hand over the control to a Rails controller.
A controller ‘controls’ the entire application by responding to the incoming requests as needed. For example, consider the following URL http ://localhost:3000/categories/show which is decoded by the controller to know that its action named show has been invoked.
All the controllers inherit only the ApplicationController which in turn inherits the ActionController::Base class. ActionContoller module provides the basic support for the controllers in Rails.
In our Cookbook application we generate Categories controller using the scaffold mechanism which populates the controller with the basic methods such as index, create, show, new, edit, update and destroy.
A simple example of index method is as follows:
<pre>
def index
@categories = Category.all

respond_to do |format|
format.html # index.html.erb
format.json { render json: @categories }
end
end

</pre>
In ruby, @ operator is used to declare instance variables. The index method makes use of @categories instance variable which is populated with all the records in the Category table. The respond_to method is used for responding to particular type of request. It contains a block and a variable |format| which determines whether the incoming request should be responded with HTML (when we are interacting with a user) or JSON format (if we are returning an object).
After executing the code, the controller will render a template of the same name. (For this example, the template is views/categories/index.html.erb).
Similarly the show method is defined as follows:
<pre>
def show
@category = Category.find(params[:id])

respond_to do |format|
format.html # show.html.erb
format.json { render json: @category }
end
end

</pre>
The show method is used to display a particular object. The show method needs to access database to search for the given object. This is done using the find method which takes params[:id] as argument. The params[:id] contains the id or primary key of the object which is passed as a parameter to look up in the database and the result is stored in the instance variable. The result is displayed by rendering the show.html.erb file.<br><br>
<b>Active Record</b><br>
In ruby, a program deals with objects which are mapped into database relational databases. This kind of mapping is facilitated by the Active Record.<br>Active Record maps the Rails classes in to database tables and rails objects into database records.
This makes it easy to perform actions on database tables by invoking the class methods. Another benefit of Active Record is database migration. Migrations can manage the evolution of a schema used by several physical databases. It’s a solution to the common problem of adding a field to make a new feature work in your local database, but being unsure of how to push that change to other developers and to the production server. With migrations, you can describe the transformations in self-contained classes that can be checked into version control systems and executed against another database that might be one, two, or five versions behind.You can find a lot more details about rails migration here[8].
<p>
<b>Method Pairs</b>
<br>There are couple of method pairs such as new-create and edit-update which are executed in sequence. In method pair one method is responsible for display preparation and the other method validates the data and attempts it to save in the database.
<pre>
def new
@category = Category.new

respond_to do |format|
format.html # new.html.erb
format.json { render json: @category }
end

end
</pre>
<pre>
def create
@category = Category.new(params[:category])

respond_to do |format|
if @category.save
format.html { redirect_to @category, notice: 'Category was successfully created.' }
format.json { render json: @category, status: :created, location: @category }
else
format.html { render action: "new" }
format.json { render json: @category.errors, status: :unprocessable_entity }
end
end
end

</pre>

The new and create methods are known as method pairs which execute in sequence. The new method is used to instantiate a new Category object whereas create method is used to successfully save the object to the database. After execution of the new method, the controller renders the new.html.erb file which displays a form to create a new Category object. The user enters the required information in the form and the object id is returned in the URL on submitting the form. Consider the following URL is generated on submitting the form: http: //localhost:3000/categories/3.
This means that Category object with id =3 will be created. The details of the object will be processed by the create method.
The controller invokes the create method to store the object in the database. An observation can be made about the @category variable in the create method.
<pre>
@category = Category.new(params[:category])
</pre>
The parameters passed in the URL after creating a new object is stored in the params hash (denoted by params[]). In this case the params[] contains an object with category_id = 3. The params[] assigns the data of object with category_id =3 to the instance variable. The data entered in the instance variable is validated using the @category.save method. If no errors are found then the object stored in the database and a message on successful creation of the object is displayed to the user. However, if the data entered in the object contains an error, the user is redirected to the new.html.erb page to resubmit the information and the errors are displayed.
Another example of such method pair is the edit and update methods. The edit method displays the table entry for an existing object, while the update method is invoked when the changes have been submitted.
</p>
<p>
<h1>Models of Cookbook Application</h1>
Model handles the data processing in a web application. Actions interact with the model to manipulate the data. Rails is capable of handling databases and this is facilitated by the model. You can base models on the Rails ActiveRecord module which contains support databases.
In our Cookbook application we have two models namely: Category and Recipe. They are represented by files category.rb and recipe.rb and each file is used to describe the relation between two classes. Let’s take a look at the two models
<br><b> category.rb</b>
<pre>
class Category < ActiveRecord::Base
has_many :recipes
end
</pre>
<br>
<b>recipe.rb</b>
<pre>class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>
</p>
<br>
*<b>Relationships in models</b>
<ul>one-to-one<br>
<pre>
class Syllabus < ActiveRecord::Base
belongs_to :course¬
end

class Course < ActiveRecord::Base
has_one :syllabus
end
</pre>
</ul><br>
<ul>many-many<br>
<pre>
class Student < ActiveRecord::Base
has_and_belongs_to_many :courses
end

class Course < ActiveRecord::Base
has_and_belongs_to_many :students
end
</pre></ul>

<br>
In Cookbook, we have many-one relationship between recipes and categories.
<p>
<h1>Views of Cookbook application</h1>
What is V in MVC? ‘V’ refers to views. Views are the actual interface that users can see. It is through views, that a user may request some data to be viewed or submits some data for processing.<br>
Views in rails are of the form file_name.html.erb. Here erb means embedded ruby. What html.erb denotes is some ruby code is embedded in HTML code. Like HTML, embedded ruby also uses tags to represent data. However, to distinguish it from the HTML code, ruby is embedded between <% %> if some non-assignment ruby operation is to be performed. If something needs to be displayed on screen, <%= %> is used.
Views are present in “app/views” folder in the rails application.
<br>
Name of the view files is same as the name of their respective controller. For e.g.:- if I have a controller movie with an action new, the corresponding view page will be new.html.erb in the app/views/movie directory.<br>
The Cookbook application views are as follows:

<b> Recipe Controller Views</b><br>
1. index.html.erb
<pre><nowiki><h1>Listing categories</h1>

<table>
<tr>
<th>Name</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @categories.each do |category| %>
<tr>
<td><%= category.name %></td>
<td><%= link_to 'Show', category %></td>
<td><%= link_to 'Edit', edit_category_path(category) %></td>
<td><%= link_to 'Destroy', category, method: :delete, data: { confirm: 'Are you sure?' } %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New Category', new_category_path %>
</nowiki></pre>

*<b><% @recipes.each do |recipe| %> </b>
Here @recipes is an instance variable of model recipe defined in index action of the controller ‘recipes’. It contains all the recipes currently present in our application. Then each recipe is taken from this instance variable and is assigned to the local variable recipe. All the subsequent lines display the recipe details (name, description and instruction).
<br>
*<b><%= link_to ‘Show’, recipe %> </b>
link_to is an ruby operator which is used to redirect the control to some other page. ‘Show’ is displayed as it is on the page and is an hyperlink. It links to a page pointed by recipe. The path is defined in the routes.rb file.
<br><br>
2. _form.html.erb
<br>
This is a partial. Partials are devices used for breaking the code in smaller, more manageable chunks. This helps in modularity and also maintain DRY principle[4]. With a partial, code for rendering a particular response is moved to its own file. So for e.g. we can use this same partial for creating and editing information, because the information involved is essentially the same.
<pre>
<%= form_for(@recipe) do |f| %>
<% if @recipe.errors.any? %>
<div id="error_explanation">
<h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>

<ul>
<% @recipe.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>

<div class="field">
<%= f.label :name %><br />
<%= f.text_field :name %>
</div>
<%= f.label :category %>
<%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %>
<div class="field">
<%= f.label :description %><br />
<%= f.text_field :description %>
</div>
<div class="field">
<%= f.label :instructions %><br />
<%= f.text_area :instructions %>
<%= f.submit %>
</div>
<% end %>
</pre>

* <b><%= form_for(@recipe) do |f| %></b>
This statement means to render a form for the instance variable @recipe.
If this page is being used for creating a new recipe, then the values for each key in the @recipe hash will be empty. If it is used for editing a recipe, @recipe will contain information corresponding to the recipe being edited.

*<b><% if @recipe.errors.any? %></b>
While saving an recipe or updating a recipe in the database, some violations may occur. Like the recipe name is left empty or its description is empty and so on. So while saving this information, database will signal some error. The errors are sent back to this page and are caught in @recipe.errors.any? statement.

*<b><%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %></b>
This statement creates a dropdown box.<br>
<ul>‘recipe’ : refers to the object to which the selected value is to be assigned. In this case , it is the recipe object</ul>
<ul>‘category_id’ : create a ‘category_id’ key in the recipe hash.</ul>
<ul>Category.all.collect {|c| [c[:name],c[:id]]} : recover all categories from the database and list them in the dropdown box. The value for each name is c[:id]. Whenever a category is selected by the user, its corresponding id is assigned to the ‘category_id’ key in the ‘recipe’ object.</ul>
<br><br>
3. new.html.erb<br>
This page is used to create a new recipe. This page simply renders the partial described above.
<pre>
<h1>New recipe</h1>
<%= render 'form' %>
<%= link_to 'Back', recipes_path %>
</pre>
*<b><%= render ‘form’ %> </b>
This statement renders the partial.
<br><br>
4. edit.html.erb
This page is used to edit a existing recipe. This page also renders the partial.
<pre>
<h1>Editing recipe</h1>
<%= render 'form' %>
<%= link_to 'Show', @recipe %> |
<%= link_to 'Back', recipes_path %>
</pre>
5. show.html.erb
This page is used to show a particular recipe requested by the user. The recipe requested is captured by the controller in the @recipe instance variable and is passed to this view.
<pre>
<p id="notice"><%= notice %></p>
<p>
<b>Name:</b>
<%= @recipe.name %>
</p>
<p>
<b>Description:</b>
<%= @recipe.description %>
</p>
<p>
<b>Instructions:</b>
<%= @recipe.instructions %>
</p>
<%= link_to 'Edit', edit_recipe_path(@recipe) %> |
<%= link_to 'Back', recipes_path %>
</pre>
<br>
<b>The Category Views are very similar to the recipe Views and can be created similarly.</b>

<h1>Conclusion</h1>

MVC was first proposed by Trygve Reenskaug in 1979. He broke applications into three types of components: models, which is responsible for maintaining the state of the application; views, which are responsible for generating a user interface; and controllers, which orchestrate the applications by receiving events from outside world, interact with model, and display an appropriate view to user. This separation of concerns led to far less computing, and in turn made the code easier to write and maintain.<br>
Use Ruby on Rails can implement MVC to build various types of web applications. The Cookbook is an easy starter. Readers can learn the basics of Ruby on Rails from this page.

<h1>References</h1>
*[1] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
*[2] http://en.wikipedia.org/wiki/Ruby_on_Rails
*[3] Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
*[4] http://en.wikipedia.org/wiki/Don't_repeat_yourself
*[5] http://guides.rubyonrails.org/getting_started.html
*[6] http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
*[7] http://en.wikipedia.org/wiki/Metaprogramming
*[8] http://net.tutsplus.com/tutorials/other/mvc-for-noobs/
<br><br>
The old wiki can be found here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4d_ch.

CSC/ECE 517 Fall 2012

2012-10-04T00:56:55Z

Nmsarda:

CSC/ECE 517 Fall 2012/ch1b 1w38

2012-10-04T00:55:50Z

Nmsarda:

<h1>Introduction</h1>

<h2>Model View Controller (MVC) Architecture</h2>

The purpose of creating MVC architecture is to have clear separation between the responsibilities of business logic and representation. In a nutshell the responsibilities are mentioned as below:

[[File:MVC.png|MVC Responsibilities]] [8]

Model-View-Controller (MVC)[1] is an architectural pattern used in software engineering.In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface.<br>
The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. Having described the responsibilities of three components let’s take a look how these components interact with each other.

[[File:MVC_architecture.PNG|MVC Architecture]]

<h2>Ruby on Rails</h2>

Ruby on Rails[2] is an MVC framework. Rails enforces a structure for application, it helps to knits the models, views, and controllers as separate chunks of functionality while the program executes. No more external configuration needed. Rails is packed with features that make you more productive, with many of the following features building on one other.<br>
<b>Metaprogramming[7]:</b> Other frameworks use extensive code generation from scratch. Metaprogramming[9] techniques use programs to write programs. Ruby is one of the best languages for metaprogramming, and Rails uses this capability well. Rails also uses code generation but relies much more on metaprogramming for the heavy lifting.<br>
<b>Active Record:</b> Rails introduces the Active Record[6] framework, which saves objects to the database. The Rails version of Active Record discovers the columns in a database schema and automatically attaches them to your domain objects using metaprogramming.<br>
<b>Convention over configuration:</b> Most web development frameworks for .NET or Java force you to write pages of configuration code. If you follow suggested naming conventions, Rails doesn't need much configuration.<br>
<b>Scaffolding:</b> You often create temporary code in the early stages of development to help get an application up quickly and see how major components work together. Rails automatically creates much of the scaffolding you'll need.<br>
<b>Built-in testing:</b> Rails creates simple automated tests you can then extend. Rails also provides supporting code called harnesses and fixtures that make test cases easier to write and run. Ruby can then execute all your automated tests with the rake utility.<br>
<b>Three environments:</b> Rails gives you three default environments: development, testing, and production. Each behaves slightly differently, making your entire software development cycle easier. For example, Rails creates a fresh copy of the Test database for each test run.

<h1>CookBook Application</h1>
Cookbook Application is a very basic Ruby on Rails application. It is a great way to understand the nuances that ‘Ruby’ has to offer. It is built keeping in mind that the reader is new to the world of ruby and is developing his/her first Ruby on Rails application.
The motive of this wiki page is to make the reader understand how the Cookbook application was built. And on the way to building this application, user will be introduced to some key concepts like Model, Views and Controllers. At the end of this page, reader must fairly be ready to start building his/her basic Ruby on Rails application.

<h2>A simple application to start -- Cookbook application</h2>

Start a new project. While creating a new project, remember to select Rails Application option as follows

[[File:Start_application.png|Start a new Application]]

When we create a Rails application, rails automatically help us create a brunch of files and folders as follows:

[[File:Listing_of_cookbook_application.png|Listing_of_cookbook_application]]

We mainly use the app directory. This is where the heart of the application is stored i.e. Models, Views and controllers.

<h2>Using scaffold to create framework</h2>
Rails scaffolding is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job.<br>
In Rubymine, we can create a scaffold by right clicking on the current Project->New->Run Rails Generator ->scaffold. This will open a dialog box to create a scaffold where we can enter the name and the attributes along with their data type. Once the scaffold has been created RubyMine will generate the model, view and controller files respectively. These files do not contain any specific methods but they provide a framework which is useful for general applications. The user can modify the MVC behavior according to his application requirements. Each scaffold has create, read, update and delete methods declared in the controller class. A user can modify the behavior of the controller through these methods.
<br>

<br>[[File:Create_Scaffold.png|Creating a new scaffold]]<br><br>
[[File:Scaffold.png|Scaffold]] [[File:New_Scaffold_Categories.png|Creating scaffold for categories]]<br><br>

In the Cookbook application we are considering a Cookbook which contains recipes for various dishes. The recipes have been divided into different categories, for example there is a recipe for ice tea which belongs to the category of beverages. There is a relationship which is created between a recipe and a category which can be expressed as an ice tea belongs to beverages. We can have many such recipes belonging to a single category, in this case many to one relationship is established.

<h1>Controllers for CookBook Application</h1>
The Cookbook application starts by entering a URL in the browser which sends the request to the web server. Since our web server supports Rails application, it will hand over the control to a Rails controller.
A controller ‘controls’ the entire application by responding to the incoming requests as needed. For example, consider the following URL http://localhost:3000/categories/show which is decoded by the controller to know that its action named show has been invoked.
All the controllers inherit only the ApplicationController which in turn inherits the ActionController::Base class. ActionContoller module provides the basic support for the controllers in Rails.
In our Cookbook application we generate Categories controller using the scaffold mechanism which populates the controller with the basic methods such as index, create, show, new, edit, update and destroy.
A simple example of index method is as follows:
<pre>
def index
@categories = Category.all

respond_to do |format|
format.html # index.html.erb
format.json { render json: @categories }
end
end

</pre>
In ruby, @ operator is used to declare instance variables. The index method makes use of @categories instance variable which is populated with all the records in the Category table. The respond_to method is used for responding to particular type of request. It contains a block and a variable |format| which determines whether the incoming request should be responded with HTML (when we are interacting with a user) or JSON format (if we are returning an object).
After executing the code, the controller will render a template of the same name. (For this example, the template is views/categories/index.html.erb).
Similarly the show method is defined as follows:
<pre>
def show
@category = Category.find(params[:id])

respond_to do |format|
format.html # show.html.erb
format.json { render json: @category }
end
end

</pre>
The show method is used to display a particular object. The show method needs to access database to search for the given object. This is done using the find method which takes params[:id] as argument. The params[:id] contains the id or primary key of the object which is passed as a parameter to look up in the database and the result is stored in the instance variable. The result is displayed by rendering the show.html.erb file.<br><br>
<b>Active Record</b><br>
In ruby, a program deals with objects which are mapped into database relational databases. This kind of mapping is facilitated by the Active Record.<br>Active Record maps the Rails classes in to database tables and rails objects into database records.
This makes it easy to perform actions on database tables by invoking the class methods. Another benefit of Active Record is database migration. Migrations can manage the evolution of a schema used by several physical databases. It’s a solution to the common problem of adding a field to make a new feature work in your local database, but being unsure of how to push that change to other developers and to the production server. With migrations, you can describe the transformations in self-contained classes that can be checked into version control systems and executed against another database that might be one, two, or five versions behind.You can find a lot more details about rails migration here[8].
<p>
<b>Method Pairs</b>
<br>There are couple of method pairs such as new-create and edit-update which are executed in sequence. In method pair one method is responsible for display preparation and the other method validates the data and attempts it to save in the database.
<pre>
def new
@category = Category.new

respond_to do |format|
format.html # new.html.erb
format.json { render json: @category }
end

end
</pre>
<pre>
def create
@category = Category.new(params[:category])

respond_to do |format|
if @category.save
format.html { redirect_to @category, notice: 'Category was successfully created.' }
format.json { render json: @category, status: :created, location: @category }
else
format.html { render action: "new" }
format.json { render json: @category.errors, status: :unprocessable_entity }
end
end
end

</pre>

The new and create methods are known as method pairs which execute in sequence. The new method is used to instantiate a new Category object whereas create method is used to successfully save the object to the database. After execution of the new method, the controller renders the new.html.erb file which displays a form to create a new Category object. The user enters the required information in the form and the object id is returned in the URL on submitting the form. Consider the following URL is generated on submitting the form: http: //localhost:3000/categories/3.
This means that Category object with id =3 will be created. The details of the object will be processed by the create method.
The controller invokes the create method to store the object in the database. An observation can be made about the @category variable in the create method.
<pre>
@category = Category.new(params[:category])
</pre>
The parameters passed in the URL after creating a new object is stored in the params hash (denoted by params[]). In this case the params[] contains an object with category_id = 3. The params[] assigns the data of object with category_id =3 to the instance variable. The data entered in the instance variable is validated using the @category.save method. If no errors are found then the object stored in the database and a message on successful creation of the object is displayed to the user. However, if the data entered in the object contains an error, the user is redirected to the new.html.erb page to resubmit the information and the errors are displayed.
Another example of such method pair is the edit and update methods. The edit method displays the table entry for an existing object, while the update method is invoked when the changes have been submitted.
</p>
<p>
<h1>Models of CookBook Application</h1>
Model handles the data processing in a web application. Actions interact with the model to manipulate the data. Rails is capable of handling databases and this is facilitated by the model. You can base models on the Rails ActiveRecord module which contains support databases.
In our Cookbook application we have two models namely: Category and Recipe. They are represented by files category.rb and recipe.rb and each file is used to describe the relation between two classes. Let’s take a look at the two models
<br><b> category.rb</b>
<pre>
class Category < ActiveRecord::Base
has_many :recipes
end
</pre>
<br>
<b>recipe.rb</b>
<pre>class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>
</p>
<br>
*<b>Relationships in models</b>
<ul>one-to-one<br>
<pre>
class Syllabus < ActiveRecord::Base
belongs_to :course¬
end

class Course < ActiveRecord::Base
has_one :syllabus
end
</pre>
</ul><br>
<ul>many-many<br>
<pre>
class Student < ActiveRecord::Base
has_and_belongs_to_many :courses
end

class Course < ActiveRecord::Base
has_and_belongs_to_many :students
end
</pre></ul>

<br>
In cookbook, we have many-one relationship between recipes and categories.
<p>
<h1>Views of Cookbook application</h1>
What is V in MVC? ‘V’ refers to views. Views are the actual interface that users can see. It is through views, that a user may request some data to be viewed or submits some data for processing.<br>
Views in rails are of the form file_name.html.erb. Here erb means embedded ruby. What html.erb denotes is some ruby code is embedded in HTML code. Like HTML, embedded ruby also uses tags to represent data. However, to distinguish it from the HTML code, ruby is embedded between <% %> if some non-assignment ruby operation is to be performed. If something needs to be displayed on screen, <%= %> is used.
Views are present in “app/views” folder in the rails application.
<br>
Name of the view files is same as the name of their respective controller. For e.g.:- if I have a controller movie with an action new, the corresponding view page will be new.html.erb in the app/views/movie directory.<br>
The cookbook application views are as follows:

<b> Recipe Controller Views</b><br>
1. index.html.erb
<pre><nowiki><h1>Listing categories</h1>

<table>
<tr>
<th>Name</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @categories.each do |category| %>
<tr>
<td><%= category.name %></td>
<td><%= link_to 'Show', category %></td>
<td><%= link_to 'Edit', edit_category_path(category) %></td>
<td><%= link_to 'Destroy', category, method: :delete, data: { confirm: 'Are you sure?' } %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New Category', new_category_path %>
</nowiki></pre>

*<b><% @recipes.each do |recipe| %> </b>
Here @recipes is an instance variable of model recipe defined in index action of the controller ‘recipes’. It contains all the recipes currently present in our application. Then each recipe is taken from this instance variable and is assigned to the local variable recipe. All the subsequent lines display the recipe details (name, description and instruction).
<br>
*<b><%= link_to ‘Show’, recipe %> </b>
link_to is an ruby operator which is used to redirect the control to some other page. ‘Show’ is displayed as it is on the page and is an hyperlink. It links to a page pointed by recipe. The path is defined in the routes.rb file.
<br><br>
2. _form.html.erb
<br>
This is a partial. Partials are devices used for breaking the code in smaller, more manageable chunks. This helps in modularity and also maintain DRY principle[4]. With a partial, code for rendering a particular response is moved to its own file. So for e.g. we can use this same partial for creating and editing information, because the information involved is essentially the same.
<pre>
<%= form_for(@recipe) do |f| %>
<% if @recipe.errors.any? %>
<div id="error_explanation">
<h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>

<ul>
<% @recipe.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>

<div class="field">
<%= f.label :name %><br />
<%= f.text_field :name %>
</div>
<%= f.label :category %>
<%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %>
<div class="field">
<%= f.label :description %><br />
<%= f.text_field :description %>
</div>
<div class="field">
<%= f.label :instructions %><br />
<%= f.text_area :instructions %>
<%= f.submit %>
</div>
<% end %>
</pre>

* <b><%= form_for(@recipe) do |f| %></b>
This statement means to render a form for the instance variable @recipe.
If this page is being used for creating a new recipe, then the values for each key in the @recipe hash will be empty. If it is used for editing a recipe, @recipe will contain information corresponding to the recipe being edited.

*<b><% if @recipe.errors.any? %></b>
While saving an recipe or updating a recipe in the database, some violations may occur. Like the recipe name is left empty or its description is empty and so on. So while saving this information, database will signal some error. The errors are sent back to this page and are caught in @recipe.errors.any? statement.

*<b><%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %></b>
This statement creates a dropdown box.<br>
<ul>‘recipe’ : refers to the object to which the selected value is to be assigned. In this case , it is the recipe object</ul>
<ul>‘category_id’ : create a ‘category_id’ key in the recipe hash.</ul>
<ul>Category.all.collect {|c| [c[:name],c[:id]]} : recover all categories from the database and list them in the dropdown box. The value for each name is c[:id]. Whenever a category is selected by the user, its corresponding id is assigned to the ‘category_id’ key in the ‘recipe’ object.</ul>
<br><br>
3. new.html.erb<br>
This page is used to create a new recipe. This page simply renders the partial described above.
<pre>
<h1>New recipe</h1>
<%= render 'form' %>
<%= link_to 'Back', recipes_path %>
</pre>
*<b><%= render ‘form’ %> </b>
This statement renders the partial.
<br><br>
4. edit.html.erb
This page is used to edit a existing recipe. This page also renders the partial.
<pre>
<h1>Editing recipe</h1>
<%= render 'form' %>
<%= link_to 'Show', @recipe %> |
<%= link_to 'Back', recipes_path %>
</pre>
5. show.html.erb
This page is used to show a particular recipe requested by the user. The recipe requested is captured by the controller in the @recipe instance variable and is passed to this view.
<pre>
<p id="notice"><%= notice %></p>
<p>
<b>Name:</b>
<%= @recipe.name %>
</p>
<p>
<b>Description:</b>
<%= @recipe.description %>
</p>
<p>
<b>Instructions:</b>
<%= @recipe.instructions %>
</p>
<%= link_to 'Edit', edit_recipe_path(@recipe) %> |
<%= link_to 'Back', recipes_path %>
</pre>
<br>
<b>The Category Views are very similar to the recipe Views and can be created similarly.</b>

<h1>Conclusion</h1>

MVC was first proposed by Trygve Reenskaug in 1979. He broke applications into three types of components: models, which is responsible for maintaining the state of the application; views, which are responsible for generating a user interface; and controllers, which orchestrate the applications by receiving events from outside world, interact with model, and display an appropriate view to user. This separation of concerns led to far less computing, and in turn made the code easier to write and maintain.<br>
Use Ruby on Rails can implement MVC to build various types of web applications. The Cookbook is an easy starter. Readers can learn the basics of Ruby on Rails from this page.

<h1>References</h1>
*[1] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
*[2] http://en.wikipedia.org/wiki/Ruby_on_Rails
*[3] Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
*[4] http://en.wikipedia.org/wiki/Don't_repeat_yourself
*[5] http://guides.rubyonrails.org/getting_started.html
*[6] http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
*[7] http://en.wikipedia.org/wiki/Metaprogramming
*[8] http://net.tutsplus.com/tutorials/other/mvc-for-noobs/
<br><br>
The old wiki can be found here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4d_ch.

CSC/ECE 517 Fall 2012/ch1b 1w38

2012-10-04T00:53:17Z

Nmsarda:

<h1>Introduction</h1>

<h2>Model View Controller (MVC) Architecture</h2>

The purpose of creating MVC architecture is to have clear separation between the responsibilities of business logic and representation. In a nutshell the responsibilities are mentioned as below:

[[File:MVC.png|MVC Responsibilities]]

Model-View-Controller (MVC)[1] is an architectural pattern used in software engineering.In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface.<br>
The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. Having described the responsibilities of three components let’s take a look how these components interact with each other.

[[File:MVC_architecture.PNG|MVC Architecture]]

<h2>Ruby on Rails</h2>

Ruby on Rails[2] is an MVC framework. Rails enforces a structure for application, it helps to knits the models, views, and controllers as separate chunks of functionality while the program executes. No more external configuration needed. Rails is packed with features that make you more productive, with many of the following features building on one other.<br>
<b>Metaprogramming[7]:</b> Other frameworks use extensive code generation from scratch. Metaprogramming[9] techniques use programs to write programs. Ruby is one of the best languages for metaprogramming, and Rails uses this capability well. Rails also uses code generation but relies much more on metaprogramming for the heavy lifting.<br>
<b>Active Record:</b> Rails introduces the Active Record[6] framework, which saves objects to the database. The Rails version of Active Record discovers the columns in a database schema and automatically attaches them to your domain objects using metaprogramming.<br>
<b>Convention over configuration:</b> Most web development frameworks for .NET or Java force you to write pages of configuration code. If you follow suggested naming conventions, Rails doesn't need much configuration.<br>
<b>Scaffolding:</b> You often create temporary code in the early stages of development to help get an application up quickly and see how major components work together. Rails automatically creates much of the scaffolding you'll need.<br>
<b>Built-in testing:</b> Rails creates simple automated tests you can then extend. Rails also provides supporting code called harnesses and fixtures that make test cases easier to write and run. Ruby can then execute all your automated tests with the rake utility.<br>
<b>Three environments:</b> Rails gives you three default environments: development, testing, and production. Each behaves slightly differently, making your entire software development cycle easier. For example, Rails creates a fresh copy of the Test database for each test run.

<h1>CookBook Application</h1>
Cookbook Application is a very basic Ruby on Rails application. It is a great way to understand the nuances that ‘Ruby’ has to offer. It is built keeping in mind that the reader is new to the world of ruby and is developing his/her first Ruby on Rails application.
The motive of this wiki page is to make the reader understand how the Cookbook application was built. And on the way to building this application, user will be introduced to some key concepts like Model, Views and Controllers. At the end of this page, reader must fairly be ready to start building his/her basic Ruby on Rails application.

<h2>A simple application to start -- Cookbook application</h2>

Start a new project. While creating a new project, remember to select Rails Application option as follows

[[File:Start_application.png|Start a new Application]]

When we create a Rails application, rails automatically help us create a brunch of files and folders as follows:

[[File:Listing_of_cookbook_application.png|Listing_of_cookbook_application]]

We mainly use the app directory. This is where the heart of the application is stored i.e. Models, Views and controllers.

<h2>Using scaffold to create framework</h2>
Rails scaffolding is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job.<br>
In Rubymine, we can create a scaffold by right clicking on the current Project->New->Run Rails Generator ->scaffold. This will open a dialog box to create a scaffold where we can enter the name and the attributes along with their data type. Once the scaffold has been created RubyMine will generate the model, view and controller files respectively. These files do not contain any specific methods but they provide a framework which is useful for general applications. The user can modify the MVC behavior according to his application requirements. Each scaffold has create, read, update and delete methods declared in the controller class. A user can modify the behavior of the controller through these methods.
<br>

<br>[[File:Create_Scaffold.png|Creating a new scaffold]]<br><br>
[[File:Scaffold.png|Scaffold]] [[File:New_Scaffold_Categories.png|Creating scaffold for categories]]<br><br>

In the Cookbook application we are considering a Cookbook which contains recipes for various dishes. The recipes have been divided into different categories, for example there is a recipe for ice tea which belongs to the category of beverages. There is a relationship which is created between a recipe and a category which can be expressed as an ice tea belongs to beverages. We can have many such recipes belonging to a single category, in this case many to one relationship is established.

<h1>Controllers for CookBook Application</h1>
The Cookbook application starts by entering a URL in the browser which sends the request to the web server. Since our web server supports Rails application, it will hand over the control to a Rails controller.
A controller ‘controls’ the entire application by responding to the incoming requests as needed. For example, consider the following URL http://localhost:3000/categories/show which is decoded by the controller to know that its action named show has been invoked.
All the controllers inherit only the ApplicationController which in turn inherits the ActionController::Base class. ActionContoller module provides the basic support for the controllers in Rails.
In our Cookbook application we generate Categories controller using the scaffold mechanism which populates the controller with the basic methods such as index, create, show, new, edit, update and destroy.
A simple example of index method is as follows:
<pre>
def index
@categories = Category.all

respond_to do |format|
format.html # index.html.erb
format.json { render json: @categories }
end
end

</pre>
In ruby, @ operator is used to declare instance variables. The index method makes use of @categories instance variable which is populated with all the records in the Category table. The respond_to method is used for responding to particular type of request. It contains a block and a variable |format| which determines whether the incoming request should be responded with HTML (when we are interacting with a user) or JSON format (if we are returning an object).
After executing the code, the controller will render a template of the same name. (For this example, the template is views/categories/index.html.erb).
Similarly the show method is defined as follows:
<pre>
def show
@category = Category.find(params[:id])

respond_to do |format|
format.html # show.html.erb
format.json { render json: @category }
end
end

</pre>
The show method is used to display a particular object. The show method needs to access database to search for the given object. This is done using the find method which takes params[:id] as argument. The params[:id] contains the id or primary key of the object which is passed as a parameter to look up in the database and the result is stored in the instance variable. The result is displayed by rendering the show.html.erb file.<br><br>
<b>Active Record</b><br>
In ruby, a program deals with objects which are mapped into database relational databases. This kind of mapping is facilitated by the Active Record.<br>Active Record maps the Rails classes in to database tables and rails objects into database records.
This makes it easy to perform actions on database tables by invoking the class methods. Another benefit of Active Record is database migration. Migrations can manage the evolution of a schema used by several physical databases. It’s a solution to the common problem of adding a field to make a new feature work in your local database, but being unsure of how to push that change to other developers and to the production server. With migrations, you can describe the transformations in self-contained classes that can be checked into version control systems and executed against another database that might be one, two, or five versions behind.You can find a lot more details about rails migration here[8].
<p>
<b>Method Pairs</b>
<br>There are couple of method pairs such as new-create and edit-update which are executed in sequence. In method pair one method is responsible for display preparation and the other method validates the data and attempts it to save in the database.
<pre>
def new
@category = Category.new

respond_to do |format|
format.html # new.html.erb
format.json { render json: @category }
end

end
</pre>
<pre>
def create
@category = Category.new(params[:category])

respond_to do |format|
if @category.save
format.html { redirect_to @category, notice: 'Category was successfully created.' }
format.json { render json: @category, status: :created, location: @category }
else
format.html { render action: "new" }
format.json { render json: @category.errors, status: :unprocessable_entity }
end
end
end

</pre>

The new and create methods are known as method pairs which execute in sequence. The new method is used to instantiate a new Category object whereas create method is used to successfully save the object to the database. After execution of the new method, the controller renders the new.html.erb file which displays a form to create a new Category object. The user enters the required information in the form and the object id is returned in the URL on submitting the form. Consider the following URL is generated on submitting the form: http: //localhost:3000/categories/3.
This means that Category object with id =3 will be created. The details of the object will be processed by the create method.
The controller invokes the create method to store the object in the database. An observation can be made about the @category variable in the create method.
<pre>
@category = Category.new(params[:category])
</pre>
The parameters passed in the URL after creating a new object is stored in the params hash (denoted by params[]). In this case the params[] contains an object with category_id = 3. The params[] assigns the data of object with category_id =3 to the instance variable. The data entered in the instance variable is validated using the @category.save method. If no errors are found then the object stored in the database and a message on successful creation of the object is displayed to the user. However, if the data entered in the object contains an error, the user is redirected to the new.html.erb page to resubmit the information and the errors are displayed.
Another example of such method pair is the edit and update methods. The edit method displays the table entry for an existing object, while the update method is invoked when the changes have been submitted.
</p>
<p>
<h1>Models of CookBook Application</h1>
Model handles the data processing in a web application. Actions interact with the model to manipulate the data. Rails is capable of handling databases and this is facilitated by the model. You can base models on the Rails ActiveRecord module which contains support databases.
In our Cookbook application we have two models namely: Category and Recipe. They are represented by files category.rb and recipe.rb and each file is used to describe the relation between two classes. Let’s take a look at the two models
<br><b> category.rb</b>
<pre>
class Category < ActiveRecord::Base
has_many :recipes
end
</pre>
<br>
<b>recipe.rb</b>
<pre>class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>
</p>
<br>
*<b>Relationships in models</b>
<ul>one-to-one<br>
<pre>
class Syllabus < ActiveRecord::Base
belongs_to :course¬
end

class Course < ActiveRecord::Base
has_one :syllabus
end
</pre>
</ul><br>
<ul>many-many<br>
<pre>
class Student < ActiveRecord::Base
has_and_belongs_to_many :courses
end

class Course < ActiveRecord::Base
has_and_belongs_to_many :students
end
</pre></ul>

<br>
In cookbook, we have many-one relationship between recipes and categories.
<p>
<h1>Views of Cookbook application</h1>
What is V in MVC? ‘V’ refers to views. Views are the actual interface that users can see. It is through views, that a user may request some data to be viewed or submits some data for processing.<br>
Views in rails are of the form file_name.html.erb. Here erb means embedded ruby. What html.erb denotes is some ruby code is embedded in HTML code. Like HTML, embedded ruby also uses tags to represent data. However, to distinguish it from the HTML code, ruby is embedded between <% %> if some non-assignment ruby operation is to be performed. If something needs to be displayed on screen, <%= %> is used.
Views are present in “app/views” folder in the rails application.
<br>
Name of the view files is same as the name of their respective controller. For e.g.:- if I have a controller movie with an action new, the corresponding view page will be new.html.erb in the app/views/movie directory.<br>
The cookbook application views are as follows:

<b> Recipe Controller Views</b><br>
1. index.html.erb
<pre><nowiki><h1>Listing categories</h1>

<table>
<tr>
<th>Name</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @categories.each do |category| %>
<tr>
<td><%= category.name %></td>
<td><%= link_to 'Show', category %></td>
<td><%= link_to 'Edit', edit_category_path(category) %></td>
<td><%= link_to 'Destroy', category, method: :delete, data: { confirm: 'Are you sure?' } %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New Category', new_category_path %>
</nowiki></pre>

*<b><% @recipes.each do |recipe| %> </b>
Here @recipes is an instance variable of model recipe defined in index action of the controller ‘recipes’. It contains all the recipes currently present in our application. Then each recipe is taken from this instance variable and is assigned to the local variable recipe. All the subsequent lines display the recipe details (name, description and instruction).
<br>
*<b><%= link_to ‘Show’, recipe %> </b>
link_to is an ruby operator which is used to redirect the control to some other page. ‘Show’ is displayed as it is on the page and is an hyperlink. It links to a page pointed by recipe. The path is defined in the routes.rb file.
<br><br>
2. _form.html.erb
<br>
This is a partial. Partials are devices used for breaking the code in smaller, more manageable chunks. This helps in modularity and also maintain DRY principle[4]. With a partial, code for rendering a particular response is moved to its own file. So for e.g. we can use this same partial for creating and editing information, because the information involved is essentially the same.
<pre>
<%= form_for(@recipe) do |f| %>
<% if @recipe.errors.any? %>
<div id="error_explanation">
<h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>

<ul>
<% @recipe.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>

<div class="field">
<%= f.label :name %><br />
<%= f.text_field :name %>
</div>
<%= f.label :category %>
<%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %>
<div class="field">
<%= f.label :description %><br />
<%= f.text_field :description %>
</div>
<div class="field">
<%= f.label :instructions %><br />
<%= f.text_area :instructions %>
<%= f.submit %>
</div>
<% end %>
</pre>

* <b><%= form_for(@recipe) do |f| %></b>
This statement means to render a form for the instance variable @recipe.
If this page is being used for creating a new recipe, then the values for each key in the @recipe hash will be empty. If it is used for editing a recipe, @recipe will contain information corresponding to the recipe being edited.

*<b><% if @recipe.errors.any? %></b>
While saving an recipe or updating a recipe in the database, some violations may occur. Like the recipe name is left empty or its description is empty and so on. So while saving this information, database will signal some error. The errors are sent back to this page and are caught in @recipe.errors.any? statement.

*<b><%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %></b>
This statement creates a dropdown box.<br>
<ul>‘recipe’ : refers to the object to which the selected value is to be assigned. In this case , it is the recipe object</ul>
<ul>‘category_id’ : create a ‘category_id’ key in the recipe hash.</ul>
<ul>Category.all.collect {|c| [c[:name],c[:id]]} : recover all categories from the database and list them in the dropdown box. The value for each name is c[:id]. Whenever a category is selected by the user, its corresponding id is assigned to the ‘category_id’ key in the ‘recipe’ object.</ul>
<br><br>
3. new.html.erb<br>
This page is used to create a new recipe. This page simply renders the partial described above.
<pre>
<h1>New recipe</h1>
<%= render 'form' %>
<%= link_to 'Back', recipes_path %>
</pre>
*<b><%= render ‘form’ %> </b>
This statement renders the partial.
<br><br>
4. edit.html.erb
This page is used to edit a existing recipe. This page also renders the partial.
<pre>
<h1>Editing recipe</h1>
<%= render 'form' %>
<%= link_to 'Show', @recipe %> |
<%= link_to 'Back', recipes_path %>
</pre>
5. show.html.erb
This page is used to show a particular recipe requested by the user. The recipe requested is captured by the controller in the @recipe instance variable and is passed to this view.
<pre>
<p id="notice"><%= notice %></p>
<p>
<b>Name:</b>
<%= @recipe.name %>
</p>
<p>
<b>Description:</b>
<%= @recipe.description %>
</p>
<p>
<b>Instructions:</b>
<%= @recipe.instructions %>
</p>
<%= link_to 'Edit', edit_recipe_path(@recipe) %> |
<%= link_to 'Back', recipes_path %>
</pre>
<br>
<b>The Category Views are very similar to the recipe Views and can be created similarly.</b>

<h1>Conclusion</h1>

MVC was first proposed by Trygve Reenskaug in 1979. He broke applications into three types of components: models, which is responsible for maintaining the state of the application; views, which are responsible for generating a user interface; and controllers, which orchestrate the applications by receiving events from outside world, interact with model, and display an appropriate view to user. This separation of concerns led to far less computing, and in turn made the code easier to write and maintain.<br>
Use Ruby on Rails can implement MVC to build various types of web applications. The Cookbook is an easy starter. Readers can learn the basics of Ruby on Rails from this page.

<h1>References</h1>
*[1] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
*[2] http://en.wikipedia.org/wiki/Ruby_on_Rails
*[3] Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
*[4] http://en.wikipedia.org/wiki/Don't_repeat_yourself
*[5] http://guides.rubyonrails.org/getting_started.html
*[6] http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
*[7] http://en.wikipedia.org/wiki/Metaprogramming
<br><br>
The old wiki can be found here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4d_ch.

File:Listing of cookbook application.png

2012-10-04T00:41:35Z

Nmsarda: Listing directory

Listing directory

CSC/ECE 517 Fall 2012/ch1b 1w38

2012-10-04T00:27:22Z

Nmsarda:

<h1><ul>Introduction</ul></h1>

<h1><ul>Model View Controller (MVC) Architecture</ul></h1>

The purpose of creating MVC architecture is to have clear separation between the responsibilities of business logic and representation. In a nutshell the responsibilities are mentioned as below:

<h1> Image </h1>

Model-View-Controller (MVC)[1] is an architectural pattern used in software engineering.In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface.<br>
The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. Having described the responsibilities of three components let’s take a look how these components interact with each other.

<h1> Image </h1>

<h1><ul>Ruby on Rails</ul></h1>

Ruby on Rails[2] is an MVC framework. Rails enforces a structure for application, it helps to knits the models, views, and controllers as separate chunks of functionality while the program executes. No more external configuration needed. Rails is packed with features that make you more productive, with many of the following features building on one other.<br>
<b>Metaprogramming[7]:</b> Other frameworks use extensive code generation from scratch. Metaprogramming[9] techniques use programs to write programs. Ruby is one of the best languages for metaprogramming, and Rails uses this capability well. Rails also uses code generation but relies much more on metaprogramming for the heavy lifting.<br>
<b>Active Record:</b> Rails introduces the Active Record[6] framework, which saves objects to the database. The Rails version of Active Record discovers the columns in a database schema and automatically attaches them to your domain objects using metaprogramming.<br>
<b>Convention over configuration:</b> Most web development frameworks for .NET or Java force you to write pages of configuration code. If you follow suggested naming conventions, Rails doesn't need much configuration.<br>
<b>Scaffolding:</b> You often create temporary code in the early stages of development to help get an application up quickly and see how major components work together. Rails automatically creates much of the scaffolding you'll need.<br>
<b>Built-in testing:</b> Rails creates simple automated tests you can then extend. Rails also provides supporting code called harnesses and fixtures that make test cases easier to write and run. Ruby can then execute all your automated tests with the rake utility.<br>
<b>Three environments:</b> Rails gives you three default environments: development, testing, and production. Each behaves slightly differently, making your entire software development cycle easier. For example, Rails creates a fresh copy of the Test database for each test run.

<h1><ul>CookBook Application</ul></h1>
Cookbook Application is a very basic Ruby on Rails application. It is a great way to understand the nuances that ‘Ruby’ has to offer. It is built keeping in mind that the reader is new to the world of ruby and is developing his/her first Ruby on Rails application.
The motive of this wiki page is to make the reader understand how the Cookbook application was built. And on the way to building this application, user will be introduced to some key concepts like Model, Views and Controllers. At the end of this page, reader must fairly be ready to start building his/her basic Ruby on Rails application.

<h1><ul>A simple application to start -- Cookbook application</ul></h1>

Start a new project. While creating a new project, remember to select Rails Application option as follows

<h1> Image </h1>

When we create a Rails application, rails automatically help us create a brunch of files and folders as follows:

<h1> Image </h1>

We mainly use the app directory. This is where the heart of the application is stored i.e. Models, Views and controllers.

<h1><ul>Using scaffold to create framework</ul></h1>
Rails scaffolding is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job.<br>
In Rubymine, we can create a scaffold by right clicking on the current Project->New->Run Rails Generator ->scaffold. This will open a dialog box to create a scaffold where we can enter the name and the attributes along with their data type. Once the scaffold has been created RubyMine will generate the model, view and controller files respectively. These files do not contain any specific methods but they provide a framework which is useful for general applications. The user can modify the MVC behavior according to his application requirements. Each scaffold has create, read, update and delete methods declared in the controller class. A user can modify the behavior of the controller through these methods.
<br>

<br>[[File:Create_Scaffold.png|Creating a new scaffold]]<br><br>
[[File:Scaffold.png|Scaffold]] [[File:New_Scaffold_Categories.png|Creating scaffold for categories]]<br><br>

In the Cookbook application we are considering a Cookbook which contains recipes for various dishes. The recipes have been divided into different categories, for example there is a recipe for ice tea which belongs to the category of beverages. There is a relationship which is created between a recipe and a category which can be expressed as an ice tea belongs to beverages. We can have many such recipes belonging to a single category, in this case many to one relationship is established.

<h1><ul>Controllers for CookBook Application</ul></h1>
The Cookbook application starts by entering a URL in the browser which sends the request to the web server. Since our web server supports Rails application, it will hand over the control to a Rails controller.
A controller ‘controls’ the entire application by responding to the incoming requests as needed. For example, consider the following URL http://localhost:3000/categories/show which is decoded by the controller to know that its action named show has been invoked.
All the controllers inherit only the ApplicationController which in turn inherits the ActionController::Base class. ActionContoller module provides the basic support for the controllers in Rails.
In our Cookbook application we generate Categories controller using the scaffold mechanism which populates the controller with the basic methods such as index, create, show, new, edit, update and destroy.
A simple example of index method is as follows:
<pre>
def index
@categories = Category.all

respond_to do |format|
format.html # index.html.erb
format.json { render json: @categories }
end
end

</pre>
In ruby, @ operator is used to declare instance variables. The index method makes use of @categories instance variable which is populated with all the records in the Category table. The respond_to method is used for responding to particular type of request. It contains a block and a variable |format| which determines whether the incoming request should be responded with HTML (when we are interacting with a user) or JSON format (if we are returning an object).
After executing the code, the controller will render a template of the same name. (For this example, the template is views/categories/index.html.erb).
Similarly the show method is defined as follows:
<pre>
def show
@category = Category.find(params[:id])

respond_to do |format|
format.html # show.html.erb
format.json { render json: @category }
end
end

</pre>
The show method is used to display a particular object. The show method needs to access database to search for the given object. This is done using the find method which takes params[:id] as argument. The params[:id] contains the id or primary key of the object which is passed as a parameter to look up in the database and the result is stored in the instance variable. The result is displayed by rendering the show.html.erb file.<br><br>
<b>Active Record</b><br>
In ruby, a program deals with objects which are mapped into database relational databases. This kind of mapping is facilitated by the Active Record.<br> <b>Active Record maps the Rails classes in to database tables and rails objects into database records.</b>
This makes it easy to perform actions on database tables by invoking the class methods. Another benefit of Active Record is database migration. Migrations can manage the evolution of a schema used by several physical databases. It’s a solution to the common problem of adding a field to make a new feature work in your local database, but being unsure of how to push that change to other developers and to the production server. With migrations, you can describe the transformations in self-contained classes that can be checked into version control systems and executed against another database that might be one, two, or five versions behind.You can find a lot more details about rails migration here[8].
<p>
<b>Method Pairs</b>
<br>There are couple of method pairs such as new-create and edit-update which are executed in sequence. In method pair one method is responsible for display preparation and the other method validates the data and attempts it to save in the database.
<pre>
def new
@category = Category.new

respond_to do |format|
format.html # new.html.erb
format.json { render json: @category }
end

end
</pre>
<pre>
def create
@category = Category.new(params[:category])

respond_to do |format|
if @category.save
format.html { redirect_to @category, notice: 'Category was successfully created.' }
format.json { render json: @category, status: :created, location: @category }
else
format.html { render action: "new" }
format.json { render json: @category.errors, status: :unprocessable_entity }
end
end
end

</pre>

The new and create methods are known as method pairs which execute in sequence. The new method is used to instantiate a new Category object whereas create method is used to successfully save the object to the database. After execution of the new method, the controller renders the new.html.erb file which displays a form to create a new Category object. The user enters the required information in the form and the object id is returned in the URL on submitting the form. Consider the following URL is generated on submitting the form: http: //localhost:3000/categories/3.
This means that Category object with id =3 will be created. The details of the object will be processed by the create method.
The controller invokes the create method to store the object in the database. An observation can be made about the @category variable in the create method.
<pre>
@category = Category.new(params[:category])
</pre>
The parameters passed in the URL after creating a new object is stored in the params hash (denoted by params[]). In this case the params[] contains an object with category_id = 3. The params[] assigns the data of object with category_id =3 to the instance variable. The data entered in the instance variable is validated using the @category.save method. If no errors are found then the object stored in the database and a message on successful creation of the object is displayed to the user. However, if the data entered in the object contains an error, the user is redirected to the new.html.erb page to resubmit the information and the errors are displayed.
Another example of such method pair is the edit and update methods. The edit method displays the table entry for an existing object, while the update method is invoked when the changes have been submitted.
</p>
<p>
<h1><ul>Models of CookBook Application</ul></h1>
Model handles the data processing in a web application. Actions interact with the model to manipulate the data. Rails is capable of handling databases and this is facilitated by the model. You can base models on the Rails ActiveRecord module which contains support databases.
In our Cookbook application we have two models namely: Category and Recipe. They are represented by files category.rb and recipe.rb and each file is used to describe the relation between two classes. Let’s take a look at the two models
<br><b> category.rb</b>
<pre>
class Category < ActiveRecord::Base
has_many :recipes
end
</pre>
<br>
<b>recipe.rb</b>
<pre>class Recipe < ActiveRecord::Base
belongs_to :category
validates :title, :presence => true
validates :instructions, :presence => true
validates :category, :presence => true
end
</pre>
</p>
<br>
*<b>Relationships in models</b>
<ul>one-to-one<br>
<pre>
class Syllabus < ActiveRecord::Base
belongs_to :course¬
end

class Course < ActiveRecord::Base
has_one :syllabus
end
</pre>
</ul><br>
<ul>many-many<br>
<pre>
class Student < ActiveRecord::Base
has_and_belongs_to_many :courses
end

class Course < ActiveRecord::Base
has_and_belongs_to_many :students
end
</pre></ul>

<br>
In cookbook, we have many-one relationship between recipes and categories.
<p>
<h1><ul>Views of Cookbook application</ul></h1>
What is V in MVC? ‘V’ refers to views. Views are the actual interface that users can see. It is through views, that a user may request some data to be viewed or submits some data for processing.<br>
Views in rails are of the form file_name.html.erb. Here erb means embedded ruby. What html.erb denotes is some ruby code is embedded in HTML code. Like HTML, embedded ruby also uses tags to represent data. However, to distinguish it from the HTML code, ruby is embedded between <% %> if some non-assignment ruby operation is to be performed. If something needs to be displayed on screen, <%= %> is used.
Views are present in “app/views” folder in the rails application.
<br>
Name of the view files is same as the name of their respective controller. For e.g.:- if I have a controller movie with an action new, the corresponding view page will be new.html.erb in the app/views/movie directory.<br>
The cookbook application views are as follows:

<b> Recipe Controller Views</b><br>
1. index.html.erb
<pre><nowiki><h1>Listing categories</h1>

<table>
<tr>
<th>Name</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @categories.each do |category| %>
<tr>
<td><%= category.name %></td>
<td><%= link_to 'Show', category %></td>
<td><%= link_to 'Edit', edit_category_path(category) %></td>
<td><%= link_to 'Destroy', category, method: :delete, data: { confirm: 'Are you sure?' } %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New Category', new_category_path %>
</nowiki></pre>

*<b><% @recipes.each do |recipe| %> </b>
Here @recipes is an instance variable of model recipe defined in index action of the controller ‘recipes’. It contains all the recipes currently present in our application. Then each recipe is taken from this instance variable and is assigned to the local variable recipe. All the subsequent lines display the recipe details (name, description and instruction).
<br>
*<b><%= link_to ‘Show’, recipe %> </b>
link_to is an ruby operator which is used to redirect the control to some other page. ‘Show’ is displayed as it is on the page and is an hyperlink. It links to a page pointed by recipe. The path is defined in the routes.rb file.
<br><br>
2. _form.html.erb
<br>
This is a partial. Partials are devices used for breaking the code in smaller, more manageable chunks. This helps in modularity and also maintain DRY principle[4]. With a partial, code for rendering a particular response is moved to its own file. So for e.g. we can use this same partial for creating and editing information, because the information involved is essentially the same.
<pre>
<%= form_for(@recipe) do |f| %>
<% if @recipe.errors.any? %>
<div id="error_explanation">
<h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>

<ul>
<% @recipe.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>

<div class="field">
<%= f.label :name %><br />
<%= f.text_field :name %>
</div>
<%= f.label :category %>
<%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %>
<div class="field">
<%= f.label :description %><br />
<%= f.text_field :description %>
</div>
<div class="field">
<%= f.label :instructions %><br />
<%= f.text_area :instructions %>
<%= f.submit %>
</div>
<% end %>
</pre>

* <b><%= form_for(@recipe) do |f| %></b>
This statement means to render a form for the instance variable @recipe.
If this page is being used for creating a new recipe, then the values for each key in the @recipe hash will be empty. If it is used for editing a recipe, @recipe will contain information corresponding to the recipe being edited.

*<b><% if @recipe.errors.any? %></b>
While saving an recipe or updating a recipe in the database, some violations may occur. Like the recipe name is left empty or its description is empty and so on. So while saving this information, database will signal some error. The errors are sent back to this page and are caught in @recipe.errors.any? statement.

*<b><%= select('recipe','category_id', Category.all.collect {|c| [c[:name],c[:id]]}) %></b>
This statement creates a dropdown box.<br>
<ul>‘recipe’ : refers to the object to which the selected value is to be assigned. In this case , it is the recipe object</ul>
<ul>‘category_id’ : create a ‘category_id’ key in the recipe hash.</ul>
<ul>Category.all.collect {|c| [c[:name],c[:id]]} : recover all categories from the database and list them in the dropdown box. The value for each name is c[:id]. Whenever a category is selected by the user, its corresponding id is assigned to the ‘category_id’ key in the ‘recipe’ object.</ul>
<br><br>
3. new.html.erb<br>
This page is used to create a new recipe. This page simply renders the partial described above.
<pre>
<h1>New recipe</h1>
<%= render 'form' %>
<%= link_to 'Back', recipes_path %>
</pre>
*<b><%= render ‘form’ %> </b>
This statement renders the partial.
<br><br>
4. edit.html.erb
This page is used to edit a existing recipe. This page also renders the partial.
<pre>
<h1>Editing recipe</h1>
<%= render 'form' %>
<%= link_to 'Show', @recipe %> |
<%= link_to 'Back', recipes_path %>
</pre>
5. show.html.erb
This page is used to show a particular recipe requested by the user. The recipe requested is captured by the controller in the @recipe instance variable and is passed to this view.
<pre>
<p id="notice"><%= notice %></p>
<p>
<b>Name:</b>
<%= @recipe.name %>
</p>
<p>
<b>Description:</b>
<%= @recipe.description %>
</p>
<p>
<b>Instructions:</b>
<%= @recipe.instructions %>
</p>
<%= link_to 'Edit', edit_recipe_path(@recipe) %> |
<%= link_to 'Back', recipes_path %>
</pre>
<br>
<b>The Category Views are very similar to the recipe Views and can be created similarly.</b>

<h1><ul>Conclusion</ul></h1>

MVC was first proposed by Trygve Reenskaug in 1979. He broke applications into three types of components: models, which is responsible for maintaining the state of the application; views, which are responsible for generating a user interface; and controllers, which orchestrate the applications by receiving events from outside world, interact with model, and display an appropriate view to user. This separation of concerns led to far less computing, and in turn made the code easier to write and maintain.<br>
Use Ruby on Rails can implement MVC to build various types of web applications. The Cookbook is an easy starter. Readers can learn the basics of Ruby on Rails from this page.

<h1><ul>References</ul></h1>
*[1] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
*[2] http://en.wikipedia.org/wiki/Ruby_on_Rails
*[3] Sam Ruby, Dave Thomas, David Heinemeier Hansson.agile web development with rails (fourth edition)
*[4] http://en.wikipedia.org/wiki/Don't_repeat_yourself
*[5] http://guides.rubyonrails.org/getting_started.html
*[6] http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
*[7] http://en.wikipedia.org/wiki/Metaprogramming