Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-31T03:00:34Z

Mknayak: /* Introduction to Expertiza */

=E818 Refactoring and testing -- analytics=
This Wiki page provides a detailed description of the Open Source Software project conducted on Expertiza, as part of the Object Oriented Languages and Systems coursework.

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is an open source project built using the Ruby on Rails platform. It is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). The source code is available at [https://github.com/expertiza/expertiza github].

= Overview of project =
===Classes:===
* analytic_controller.rb (163 lines)
* assignment_analytic.rb (206 lines)
* assignment_team_analytic.rb (126 lines)
* course_analytic.rb (142 lines)
* question_analytic.rb (12 lines)
* questionnaire_analytic.rb (55 lines)
* response_analytic.rb (101 lines)
* score_analytic.rb (12 lines)

===What they do:===
Display information about various system components in summary form, to aid in analysis.

===What was done:===
Analytic_controller.rb and course_analytic.rb had much duplicated code, which was be factored out. Additionally, analytic_controller.rb had methods that were too complicated, and were be separated into shorter, well-named methods, to make the operation of the class more transparent. Rest of the modules had duplicate code, which was refactored out.

= Analysis =
We used [https://codeclimate.com/github/expertiza/expertiza/code?q=analytic CodeClimate] to analyse the existing code. As can been be seen, there are several classes with duplicate code, high complexity and code smells. 

[[File:code_clime_old.png]]

*High complexity - AnalyticController, CourseAnalytic, QuestionnaireAnalytic
*Duplication – AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
*Smells - AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
 As regards complexity, along with a high overall complexity, the classes also have a high complexity per method ratio

=Design Changes=
Due to a lot of duplication of code that occurred in the AssignmentAnalytic, AssignmentTeamAnalytic and CourseAnalytic module, there was a definite need to refactor the duplicate code and extract out the duplication by moving the common trends in the code to a common module named as CommonAnalytic.

Here is the original design which has a lot of code duplication particularly in the modules AssignmentAnalytic, AssignmentTeamAnalytic and CourseAnalytic.

[[File:Original_expertiza.jpg]]

Thus the figure below gives the refactored design which removes the common and duplicate code from AssignmentAnalytic, AssignmentTeamAnalytic and CourseAnalytic module and moves them to a common module CommonAnalytic.

[[File:New_refactor.jpg|center|refactored expertiza design for analytic]]

In a similar way the modules ScoreAnalytic and QuestionAnalytic had redundant and duplicate code for getting word count, character count and unique character count. Thus again there was a need to refactor the duplicate code and extract out the duplication and move it a CountAnalytic module which would act as a center module thereby allowing ScoreAnalytic and QuestionAnalytic to delegate functions such as word count, character count and unique character count to the CountAnalytic module as shown below.

[[File:Slide1.jpg|center|countQuestion]]

=Code changes=

==Refactoring in AnalyticController==
=== Usage of inbuilt methods.===
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = Array.new
courses.each do |course|
course_list << [course.name, course.id]
end
respond_to do |format|
format.json { render :json => sort_by_name(course_list) }
end
end
</pre>
'''After refactoring'''
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = courses.map { |course| [course.name, course.id] }
render :json => sort_by_name(course_list)
end
</pre>

The above refactoring was applied to team_list and assignment_list as well.

===Use of hashes===

<pre>
case params[:type]
when "line"
chart_data = line_graph_data(params[:scope], params[:id], params[:data_type])
when "bar"
chart_data = bar_chart_data(params[:scope], params[:id], params[:data_type])
when "scatter"
chart_data = scatter_plot_data(params[:scope], params[:id], params[:data_type])
when "pie"
chart_data = pie_chart_data(params[:scope], params[:id], params[:data_type])
end

</pre>

Hash was used to adhere to the DRY principle.
<pre>
graph_method_name = {'line' => 'line_graph_data',
'bar' => 'bar_chart_data',
'scatter' => 'scatter_plot_data',
'pie' => 'pie_graph_data'}
graph_data = send(graph_method_name[graph_type], scope, id, data_type)
</pre>

===Methods complexity===
Complex methods were broken down into smaller methods to enhance readability.

== Refactoring in Modules ==

===Code movement===
The modules were initially placed in '''app/models/''' . They were moved to '''/lib/''' folder

===Code Changes===

At many places the developers had added the logic to find, map, get unique object, etc. which already exist in Enumerable module. We changed the code to use these in-built methods. Some of the examples of such changes are:
:1. Code before refactor [self.questionnaire_unique? in assignment_analytic.rb]
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
assignment.questionnaire_types.each do |questionnaire_type|
questionnaire_list = Array.new
assignment.questionnaires.each do |questionnaire|
if questionnaire.type == questionnaire_type
questionnaire_list << questionnaire
end
if questionnaire_list.count > 1
return false
end
end
end
end
return true
end
</pre>

:'''Code after refactoring.''' Here the inbuilt uniq method was used. If there are duplicates, then unique array length will be less than actual length.
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
questionnaires = assignment.questionnaires
return false if questionnaires.uniq { |q| q.type }.length < questionnaires.length
end
return true
end
</pre>

:2. Code before refactoring [ questionnaire_of_type(type_name_in_string) in assignment_analytic.rb ]
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.each do |questionnaire|
if questionnaire.type == type_name_in_string
return questionnaire
end
end
end
</pre>

:'''Code after refactoring:''' The find method was used here.
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.find { |questionnaire| questionnaire == type_name_in_string }
end
</pre>

:3 '''Code before refactoring [average_num_team_reviews in assignment_analytic ]'''. This pattern existed in many classes.
<pre>
def average_num_team_reviews
if num_teams == 0
0
else
total_num_team_reviews.to_f/num_teams
end
end
</pre>

:'''Code after refactoring:'''
<pre>
def average_num_team_reviews
total_num_team_reviews.to_f/num_teams
rescue ZeroDivisionError
0
end
</pre>

The code consisted of several functions with unnecessary complexity. We refactored the code to reduce the complexity. 
The code consisted of several functions that had duplicate code. These methods transformed a list of objects into a list of one of the object’s attributes. This pattern was removed by creating a generic function.
Following was one of the pattern that existed:

<pre>
# Expertiza code before refactoring in assignment_analytic.rb
def team_review_counts
list = Array.new
self.teams.each do |team|
list << team.num_reviews
end
if (list.empty?)
[0]
else
list
end
end
</pre>

The refactored code for the above logic:

<pre>
# Helper function moved to common_analytic.rb
def extract_from_list(list, property)
list.map { |item| item.send(property) }
end

# Method in assignment_analytic.rb
def team_review_counts
extract_from_list self.teams, :num_reviews
(list.empty?) ? [0] : list
end
</pre>

The logic of the method was exactly what the map method does. Futher, a ternary if-else was used to enhance readability.

The above pattern accounted for majority of the duplicate code.
Code before refactoring [self.types in QuestionnaireAnalytic ]
<pre>
def self.types
type_list = Array.new
self.all.each do |questionnaire|
if !type_list.include?(questionnaire.type)
type_list << questionnaire.type
end
end
type_list
end
</pre>

Code after refactoring.
<pre>
def self.types
type_list = extract_from_list self.all, :type
type_list.uniq
end
</pre>

The following is a list of methods and classes changed for refactoring:
#assignment_analytic.rb
##self.questionnaire_unique?
##questionnaire_of_type
##team_review_counts
##team_scores
#course_analytic.rb
##average_num_assignment_teams
##average_assignment_score
##assignment_review_counts
##assignment_team_counts
##assignment_average_scores
##assignment_max_scores
##assignment_min_scores
#assignment_team_analytic.rb
##average_review_word_count
##average_review_score
##average_review_character_count
##review_character_counts
##review_scores
##review_word_counts
#questionnaire_analytic.rb
##questions_text_list
##word_count_list
##character_count_list
#response_analytic.rb
##word_count_list
##character_count_list
##question_score_list
##comments_text_list

= Post-refactoring report=
[[File:code_clime_new.png]]

Here is a summary of the results.

[[File:Report.png]]

=Future work=
#Currently only bar charts can be seen. Further work can be done to get different kinds of graphs such as pie chart, scatter plot, etc.
#There are some requests that take a long time to respond. For example, View Scores Request. They can be optimized to reduce the response time.

=External Links=

#http://guides.rubyonrails.org/ A guide for Ruby on Rails
#http://c2.com/cgi/wiki?WhatIsRefactoring What is Refactoring?
#https://codeclimate.com/ Automated Code Review
#https://github.com/expertiza/expertiza
#https://github.com/bbatsov/ruby-style-guide Ruby Style Guide

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T19:07:02Z

Mknayak: /* Refactoring in AnalyticController */

=E818 Refactoring and testing -- analytics=
This Wiki page provides a detailed description of the Open Source Software project conducted on Expertiza, as part of the Object Oriented Languages and Systems coursework.

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is an open source project built using the Ruby on Rails platform. It is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities to manage peer reviews in coursework. The source code can be forked from [https://github.com/expertiza/expertiza github] and cloned for performing modifications. The Expertiza environment is already set up in NC State's VCL image "Ruby on Rails". If you have access, this is quickest way to get a development environment running for Expertiza. See the Expertiza wiki(provide hyperlink) on developing Expertiza on the VCL.

= Overview of project =
===Classes:===
* analytic_controller.rb (163 lines)
* assignment_analytic.rb (206 lines)
* assignment_team_analytic.rb (126 lines)
* course_analytic.rb (142 lines)
* question_analytic.rb (12 lines)
* questionnaire_analytic.rb (55 lines)
* response_analytic.rb (101 lines)
* score_analytic.rb (12 lines)

===What they do:===
Display information about various system components in summary form, to aid in analysis.

===What was done:===
Analytic_controller.rb and course_analytic.rb had much duplicated code, which was be factored out. Additionally, analytic_controller.rb had methods that were too complicated, and were be separated into shorter, well-named methods, to make the operation of the class more transparent. Rest of the modules had duplicate code, which was refactored out.

= Analysis =
We used [https://codeclimate.com/github/expertiza/expertiza/code?q=analytic CodeClimate] to analyse the existing code. As can been be seen, there are several classes with duplicate code, high complexity and code smells. 

[[File:code_clime_old.png]]

*High complexity - AnalyticController, CourseAnalytic, QuestionnaireAnalytic
*Duplication – AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
*Smells - AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
 As regards complexity, along with a high overall complexity, the classes also have a high complexity per method ratio

=Design Changes=

=Code changes=

==Refactoring in AnalyticController==
=== Usage of inbuilt methods.===
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = Array.new
courses.each do |course|
course_list << [course.name, course.id]
end
respond_to do |format|
format.json { render :json => sort_by_name(course_list) }
end
end
</pre>
'''After refactoring'''
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = courses.map { |course| [course.name, course.id] }
render :json => sort_by_name(course_list)
end
</pre>

The above refactoring was applied to team_list and assignment_list as well.

===Use of hashes===

<pre>
case params[:type]
when "line"
chart_data = line_graph_data(params[:scope], params[:id], params[:data_type])
when "bar"
chart_data = bar_chart_data(params[:scope], params[:id], params[:data_type])
when "scatter"
chart_data = scatter_plot_data(params[:scope], params[:id], params[:data_type])
when "pie"
chart_data = pie_chart_data(params[:scope], params[:id], params[:data_type])
end

</pre>

Hash was used to adhere to the DRY principle.
<pre>
graph_method_name = {'line' => 'line_graph_data',
'bar' => 'bar_chart_data',
'scatter' => 'scatter_plot_data',
'pie' => 'pie_graph_data'}
graph_data = send(graph_method_name[graph_type], scope, id, data_type)
</pre>

===Methods complexity===
Complex methods were broken down into smaller methods to enhance readability.

== Refactoring in Modules ==

===Code movement===
The modules were initially placed in '''app/models/''' . They were moved to '''/lib/''' folder

===Code Changes===

At many places the developers had added the logic to find, map, get unique object, etc. which already exist in Enumerable module. We changed the code to use these in-built methods. Some of the examples of such changes are:
:1. Code before refactor [self.questionnaire_unique? in assignment_analytic.rb]
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
assignment.questionnaire_types.each do |questionnaire_type|
questionnaire_list = Array.new
assignment.questionnaires.each do |questionnaire|
if questionnaire.type == questionnaire_type
questionnaire_list << questionnaire
end
if questionnaire_list.count > 1
return false
end
end
end
end
return true
end
</pre>

:'''Code after refactoring.''' Here the inbuilt uniq method was used. If there are duplicates, then unique array length will be less than actual length.
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
questionnaires = assignment.questionnaires
return false if questionnaires.uniq { |q| q.type }.length < questionnaires.length
end
return true
end
</pre>

:2. Code before refactoring [ questionnaire_of_type(type_name_in_string) in assignment_analytic.rb ]
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.each do |questionnaire|
if questionnaire.type == type_name_in_string
return questionnaire
end
end
end
</pre>

:'''Code after refactoring:''' The find method was used here.
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.find { |questionnaire| questionnaire == type_name_in_string }
end
</pre>

:3 '''Code before refactoring [average_num_team_reviews in assignment_analytic ]'''. This pattern existed in many classes.
<pre>
def average_num_team_reviews
if num_teams == 0
0
else
total_num_team_reviews.to_f/num_teams
end
end
</pre>

:'''Code after refactoring:'''
<pre>
def average_num_team_reviews
total_num_team_reviews.to_f/num_teams
rescue ZeroDivisionError
0
end
</pre>

The code consisted of several functions with unnecessary complexity. We refactored the code to reduce the complexity. 
The code consisted of several functions that had duplicate code. These methods transformed a list of objects into a list of one of the object’s attributes. This pattern was removed by creating a generic function.
Following was one of the pattern that existed:

<pre>
# Expertiza code before refactoring in assignment_analytic.rb
def team_review_counts
list = Array.new
self.teams.each do |team|
list << team.num_reviews
end
if (list.empty?)
[0]
else
list
end
end
</pre>

The refactored code for the above logic:

<pre>
# Helper function moved to common_analytic.rb
def extract_from_list(list, property)
list.map { |item| item.send(property) }
end

# Method in assignment_analytic.rb
def team_review_counts
extract_from_list self.teams, :num_reviews
(list.empty?) ? [0] : list
end
</pre>

The logic of the method was exactly what the map method does. Futher, a ternary if-else was used to enhance readability.

The above pattern accounted for majority of the duplicate code.
Code before refactoring [self.types in QuestionnaireAnalytic ]
<pre>
def self.types
type_list = Array.new
self.all.each do |questionnaire|
if !type_list.include?(questionnaire.type)
type_list << questionnaire.type
end
end
type_list
end
</pre>

Code after refactoring.
<pre>
def self.types
type_list = extract_from_list self.all, :type
type_list.uniq
end
</pre>

The following is a list of methods and classes changed for refactoring:
#assignment_analytic.rb
##self.questionnaire_unique?
##questionnaire_of_type
##team_review_counts
##team_scores
#course_analytic.rb
##average_num_assignment_teams
##average_assignment_score
##assignment_review_counts
##assignment_team_counts
##assignment_average_scores
##assignment_max_scores
##assignment_min_scores
#assignment_team_analytic.rb
##average_review_word_count
##average_review_score
##average_review_character_count
##review_character_counts
##review_scores
##review_word_counts
#questionnaire_analytic.rb
##questions_text_list
##word_count_list
##character_count_list
#response_analytic.rb
##word_count_list
##character_count_list
##question_score_list
##comments_text_list

= Post-refactoring report=
[[File:code_clime_new.png]]

Here is a summary of the results.

[[File:Report.png]]

=Future work=
#Currently only bar charts can be seen. Further work can be done to get different kinds of graphs such as pie chart, scatter plot, etc.
#There are some requests that take a long time to respond. For example, View Scores Request. They can be optimized to reduce the response time.

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T19:06:29Z

Mknayak: /* Refactoring in AnalyticController */

=E818 Refactoring and testing -- analytics=
This Wiki page provides a detailed description of the Open Source Software project conducted on Expertiza, as part of the Object Oriented Languages and Systems coursework.

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is an open source project built using the Ruby on Rails platform. It is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities to manage peer reviews in coursework. The source code can be forked from [https://github.com/expertiza/expertiza github] and cloned for performing modifications. The Expertiza environment is already set up in NC State's VCL image "Ruby on Rails". If you have access, this is quickest way to get a development environment running for Expertiza. See the Expertiza wiki(provide hyperlink) on developing Expertiza on the VCL.

= Overview of project =
===Classes:===
* analytic_controller.rb (163 lines)
* assignment_analytic.rb (206 lines)
* assignment_team_analytic.rb (126 lines)
* course_analytic.rb (142 lines)
* question_analytic.rb (12 lines)
* questionnaire_analytic.rb (55 lines)
* response_analytic.rb (101 lines)
* score_analytic.rb (12 lines)

===What they do:===
Display information about various system components in summary form, to aid in analysis.

===What was done:===
Analytic_controller.rb and course_analytic.rb had much duplicated code, which was be factored out. Additionally, analytic_controller.rb had methods that were too complicated, and were be separated into shorter, well-named methods, to make the operation of the class more transparent. Rest of the modules had duplicate code, which was refactored out.

= Analysis =
We used [https://codeclimate.com/github/expertiza/expertiza/code?q=analytic CodeClimate] to analyse the existing code. As can been be seen, there are several classes with duplicate code, high complexity and code smells. 

[[File:code_clime_old.png]]

*High complexity - AnalyticController, CourseAnalytic, QuestionnaireAnalytic
*Duplication – AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
*Smells - AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
 As regards complexity, along with a high overall complexity, the classes also have a high complexity per method ratio

=Design Changes=

=Code changes=

==Refactoring in AnalyticController==
:1 Usage of inbuilt methods.
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = Array.new
courses.each do |course|
course_list << [course.name, course.id]
end
respond_to do |format|
format.json { render :json => sort_by_name(course_list) }
end
end
</pre>
'''After refactoring'''
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = courses.map { |course| [course.name, course.id] }
render :json => sort_by_name(course_list)
end
</pre>

The above refactoring was applied to team_list and assignment_list as well.

:2 Use of hashes

<pre>
case params[:type]
when "line"
chart_data = line_graph_data(params[:scope], params[:id], params[:data_type])
when "bar"
chart_data = bar_chart_data(params[:scope], params[:id], params[:data_type])
when "scatter"
chart_data = scatter_plot_data(params[:scope], params[:id], params[:data_type])
when "pie"
chart_data = pie_chart_data(params[:scope], params[:id], params[:data_type])
end

</pre>

Hash was used to adhere to the DRY principle.
<pre>
graph_method_name = {'line' => 'line_graph_data',
'bar' => 'bar_chart_data',
'scatter' => 'scatter_plot_data',
'pie' => 'pie_graph_data'}
graph_data = send(graph_method_name[graph_type], scope, id, data_type)
</pre>

:3 Methods complexity
Complex methods were broken down into smaller methods to enhance readability.

== Refactoring in Modules ==

===Code movement===
The modules were initially placed in '''app/models/''' . They were moved to '''/lib/''' folder

===Code Changes===

At many places the developers had added the logic to find, map, get unique object, etc. which already exist in Enumerable module. We changed the code to use these in-built methods. Some of the examples of such changes are:
:1. Code before refactor [self.questionnaire_unique? in assignment_analytic.rb]
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
assignment.questionnaire_types.each do |questionnaire_type|
questionnaire_list = Array.new
assignment.questionnaires.each do |questionnaire|
if questionnaire.type == questionnaire_type
questionnaire_list << questionnaire
end
if questionnaire_list.count > 1
return false
end
end
end
end
return true
end
</pre>

:'''Code after refactoring.''' Here the inbuilt uniq method was used. If there are duplicates, then unique array length will be less than actual length.
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
questionnaires = assignment.questionnaires
return false if questionnaires.uniq { |q| q.type }.length < questionnaires.length
end
return true
end
</pre>

:2. Code before refactoring [ questionnaire_of_type(type_name_in_string) in assignment_analytic.rb ]
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.each do |questionnaire|
if questionnaire.type == type_name_in_string
return questionnaire
end
end
end
</pre>

:'''Code after refactoring:''' The find method was used here.
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.find { |questionnaire| questionnaire == type_name_in_string }
end
</pre>

:3 '''Code before refactoring [average_num_team_reviews in assignment_analytic ]'''. This pattern existed in many classes.
<pre>
def average_num_team_reviews
if num_teams == 0
0
else
total_num_team_reviews.to_f/num_teams
end
end
</pre>

:'''Code after refactoring:'''
<pre>
def average_num_team_reviews
total_num_team_reviews.to_f/num_teams
rescue ZeroDivisionError
0
end
</pre>

The code consisted of several functions with unnecessary complexity. We refactored the code to reduce the complexity. 
The code consisted of several functions that had duplicate code. These methods transformed a list of objects into a list of one of the object’s attributes. This pattern was removed by creating a generic function.
Following was one of the pattern that existed:

<pre>
# Expertiza code before refactoring in assignment_analytic.rb
def team_review_counts
list = Array.new
self.teams.each do |team|
list << team.num_reviews
end
if (list.empty?)
[0]
else
list
end
end
</pre>

The refactored code for the above logic:

<pre>
# Helper function moved to common_analytic.rb
def extract_from_list(list, property)
list.map { |item| item.send(property) }
end

# Method in assignment_analytic.rb
def team_review_counts
extract_from_list self.teams, :num_reviews
(list.empty?) ? [0] : list
end
</pre>

The logic of the method was exactly what the map method does. Futher, a ternary if-else was used to enhance readability.

The above pattern accounted for majority of the duplicate code.
Code before refactoring [self.types in QuestionnaireAnalytic ]
<pre>
def self.types
type_list = Array.new
self.all.each do |questionnaire|
if !type_list.include?(questionnaire.type)
type_list << questionnaire.type
end
end
type_list
end
</pre>

Code after refactoring.
<pre>
def self.types
type_list = extract_from_list self.all, :type
type_list.uniq
end
</pre>

The following is a list of methods and classes changed for refactoring:
#assignment_analytic.rb
##self.questionnaire_unique?
##questionnaire_of_type
##team_review_counts
##team_scores
#course_analytic.rb
##average_num_assignment_teams
##average_assignment_score
##assignment_review_counts
##assignment_team_counts
##assignment_average_scores
##assignment_max_scores
##assignment_min_scores
#assignment_team_analytic.rb
##average_review_word_count
##average_review_score
##average_review_character_count
##review_character_counts
##review_scores
##review_word_counts
#questionnaire_analytic.rb
##questions_text_list
##word_count_list
##character_count_list
#response_analytic.rb
##word_count_list
##character_count_list
##question_score_list
##comments_text_list

= Post-refactoring report=
[[File:code_clime_new.png]]

Here is a summary of the results.

[[File:Report.png]]

=Future work=
#Currently only bar charts can be seen. Further work can be done to get different kinds of graphs such as pie chart, scatter plot, etc.
#There are some requests that take a long time to respond. For example, View Scores Request. They can be optimized to reduce the response time.

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T19:05:54Z

Mknayak: /* Refactoring in AnalyticController */

=E818 Refactoring and testing -- analytics=
This Wiki page provides a detailed description of the Open Source Software project conducted on Expertiza, as part of the Object Oriented Languages and Systems coursework.

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is an open source project built using the Ruby on Rails platform. It is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities to manage peer reviews in coursework. The source code can be forked from [https://github.com/expertiza/expertiza github] and cloned for performing modifications. The Expertiza environment is already set up in NC State's VCL image "Ruby on Rails". If you have access, this is quickest way to get a development environment running for Expertiza. See the Expertiza wiki(provide hyperlink) on developing Expertiza on the VCL.

= Overview of project =
===Classes:===
* analytic_controller.rb (163 lines)
* assignment_analytic.rb (206 lines)
* assignment_team_analytic.rb (126 lines)
* course_analytic.rb (142 lines)
* question_analytic.rb (12 lines)
* questionnaire_analytic.rb (55 lines)
* response_analytic.rb (101 lines)
* score_analytic.rb (12 lines)

===What they do:===
Display information about various system components in summary form, to aid in analysis.

===What was done:===
Analytic_controller.rb and course_analytic.rb had much duplicated code, which was be factored out. Additionally, analytic_controller.rb had methods that were too complicated, and were be separated into shorter, well-named methods, to make the operation of the class more transparent. Rest of the modules had duplicate code, which was refactored out.

= Analysis =
We used [https://codeclimate.com/github/expertiza/expertiza/code?q=analytic CodeClimate] to analyse the existing code. As can been be seen, there are several classes with duplicate code, high complexity and code smells. 

[[File:code_clime_old.png]]

*High complexity - AnalyticController, CourseAnalytic, QuestionnaireAnalytic
*Duplication – AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
*Smells - AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
 As regards complexity, along with a high overall complexity, the classes also have a high complexity per method ratio

=Design Changes=

=Code changes=

==Refactoring in AnalyticController==
:1 Usage of inbuilt methods.
:Before
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = Array.new
courses.each do |course|
course_list << [course.name, course.id]
end
respond_to do |format|
format.json { render :json => sort_by_name(course_list) }
end
end
</pre>
:After
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = courses.map { |course| [course.name, course.id] }
render :json => sort_by_name(course_list)
end
</pre>

The above refactoring was applied to team_list and assignment_list as well.

:2 Use of hashes

<pre>
case params[:type]
when "line"
chart_data = line_graph_data(params[:scope], params[:id], params[:data_type])
when "bar"
chart_data = bar_chart_data(params[:scope], params[:id], params[:data_type])
when "scatter"
chart_data = scatter_plot_data(params[:scope], params[:id], params[:data_type])
when "pie"
chart_data = pie_chart_data(params[:scope], params[:id], params[:data_type])
end

</pre>

Hash was used to adhere to the DRY principle.
<pre>
graph_method_name = {'line' => 'line_graph_data',
'bar' => 'bar_chart_data',
'scatter' => 'scatter_plot_data',
'pie' => 'pie_graph_data'}
graph_data = send(graph_method_name[graph_type], scope, id, data_type)
</pre>

:3 Methods complexity
Complex methods were broken down into smaller methods to enhance readability.

== Refactoring in Modules ==

===Code movement===
The modules were initially placed in '''app/models/''' . They were moved to '''/lib/''' folder

===Code Changes===

At many places the developers had added the logic to find, map, get unique object, etc. which already exist in Enumerable module. We changed the code to use these in-built methods. Some of the examples of such changes are:
:1. Code before refactor [self.questionnaire_unique? in assignment_analytic.rb]
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
assignment.questionnaire_types.each do |questionnaire_type|
questionnaire_list = Array.new
assignment.questionnaires.each do |questionnaire|
if questionnaire.type == questionnaire_type
questionnaire_list << questionnaire
end
if questionnaire_list.count > 1
return false
end
end
end
end
return true
end
</pre>

:'''Code after refactoring.''' Here the inbuilt uniq method was used. If there are duplicates, then unique array length will be less than actual length.
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
questionnaires = assignment.questionnaires
return false if questionnaires.uniq { |q| q.type }.length < questionnaires.length
end
return true
end
</pre>

:2. Code before refactoring [ questionnaire_of_type(type_name_in_string) in assignment_analytic.rb ]
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.each do |questionnaire|
if questionnaire.type == type_name_in_string
return questionnaire
end
end
end
</pre>

:'''Code after refactoring:''' The find method was used here.
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.find { |questionnaire| questionnaire == type_name_in_string }
end
</pre>

:3 '''Code before refactoring [average_num_team_reviews in assignment_analytic ]'''. This pattern existed in many classes.
<pre>
def average_num_team_reviews
if num_teams == 0
0
else
total_num_team_reviews.to_f/num_teams
end
end
</pre>

:'''Code after refactoring:'''
<pre>
def average_num_team_reviews
total_num_team_reviews.to_f/num_teams
rescue ZeroDivisionError
0
end
</pre>

The code consisted of several functions with unnecessary complexity. We refactored the code to reduce the complexity. 
The code consisted of several functions that had duplicate code. These methods transformed a list of objects into a list of one of the object’s attributes. This pattern was removed by creating a generic function.
Following was one of the pattern that existed:

<pre>
# Expertiza code before refactoring in assignment_analytic.rb
def team_review_counts
list = Array.new
self.teams.each do |team|
list << team.num_reviews
end
if (list.empty?)
[0]
else
list
end
end
</pre>

The refactored code for the above logic:

<pre>
# Helper function moved to common_analytic.rb
def extract_from_list(list, property)
list.map { |item| item.send(property) }
end

# Method in assignment_analytic.rb
def team_review_counts
extract_from_list self.teams, :num_reviews
(list.empty?) ? [0] : list
end
</pre>

The logic of the method was exactly what the map method does. Futher, a ternary if-else was used to enhance readability.

The above pattern accounted for majority of the duplicate code.
Code before refactoring [self.types in QuestionnaireAnalytic ]
<pre>
def self.types
type_list = Array.new
self.all.each do |questionnaire|
if !type_list.include?(questionnaire.type)
type_list << questionnaire.type
end
end
type_list
end
</pre>

Code after refactoring.
<pre>
def self.types
type_list = extract_from_list self.all, :type
type_list.uniq
end
</pre>

The following is a list of methods and classes changed for refactoring:
#assignment_analytic.rb
##self.questionnaire_unique?
##questionnaire_of_type
##team_review_counts
##team_scores
#course_analytic.rb
##average_num_assignment_teams
##average_assignment_score
##assignment_review_counts
##assignment_team_counts
##assignment_average_scores
##assignment_max_scores
##assignment_min_scores
#assignment_team_analytic.rb
##average_review_word_count
##average_review_score
##average_review_character_count
##review_character_counts
##review_scores
##review_word_counts
#questionnaire_analytic.rb
##questions_text_list
##word_count_list
##character_count_list
#response_analytic.rb
##word_count_list
##character_count_list
##question_score_list
##comments_text_list

= Post-refactoring report=
[[File:code_clime_new.png]]

Here is a summary of the results.

[[File:Report.png]]

=Future work=
#Currently only bar charts can be seen. Further work can be done to get different kinds of graphs such as pie chart, scatter plot, etc.
#There are some requests that take a long time to respond. For example, View Scores Request. They can be optimized to reduce the response time.

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T19:04:16Z

Mknayak:

=E818 Refactoring and testing -- analytics=
This Wiki page provides a detailed description of the Open Source Software project conducted on Expertiza, as part of the Object Oriented Languages and Systems coursework.

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is an open source project built using the Ruby on Rails platform. It is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities to manage peer reviews in coursework. The source code can be forked from [https://github.com/expertiza/expertiza github] and cloned for performing modifications. The Expertiza environment is already set up in NC State's VCL image "Ruby on Rails". If you have access, this is quickest way to get a development environment running for Expertiza. See the Expertiza wiki(provide hyperlink) on developing Expertiza on the VCL.

= Overview of project =
===Classes:===
* analytic_controller.rb (163 lines)
* assignment_analytic.rb (206 lines)
* assignment_team_analytic.rb (126 lines)
* course_analytic.rb (142 lines)
* question_analytic.rb (12 lines)
* questionnaire_analytic.rb (55 lines)
* response_analytic.rb (101 lines)
* score_analytic.rb (12 lines)

===What they do:===
Display information about various system components in summary form, to aid in analysis.

===What was done:===
Analytic_controller.rb and course_analytic.rb had much duplicated code, which was be factored out. Additionally, analytic_controller.rb had methods that were too complicated, and were be separated into shorter, well-named methods, to make the operation of the class more transparent. Rest of the modules had duplicate code, which was refactored out.

= Analysis =
We used [https://codeclimate.com/github/expertiza/expertiza/code?q=analytic CodeClimate] to analyse the existing code. As can been be seen, there are several classes with duplicate code, high complexity and code smells. 

[[File:code_clime_old.png]]

*High complexity - AnalyticController, CourseAnalytic, QuestionnaireAnalytic
*Duplication – AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
*Smells - AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
 As regards complexity, along with a high overall complexity, the classes also have a high complexity per method ratio

=Design Changes=

=Code changes=

==Refactoring in AnalyticController==
:1 Usage of inbuilt methods.
Before
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = Array.new
courses.each do |course|
course_list << [course.name, course.id]
end
respond_to do |format|
format.json { render :json => sort_by_name(course_list) }
end
end
</pre>
 After
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = courses.map { |course| [course.name, course.id] }
render :json => sort_by_name(course_list)
end
</pre>

The above refactoring was applied to team_list and assignment_list as well.

:2 Use of hashes

<pre>
case params[:type]
when "line"
chart_data = line_graph_data(params[:scope], params[:id], params[:data_type])
when "bar"
chart_data = bar_chart_data(params[:scope], params[:id], params[:data_type])
when "scatter"
chart_data = scatter_plot_data(params[:scope], params[:id], params[:data_type])
when "pie"
chart_data = pie_chart_data(params[:scope], params[:id], params[:data_type])
end

</pre>

Hash was used to adhere to the DRY principle.
<pre>
graph_method_name = {'line' => 'line_graph_data',
'bar' => 'bar_chart_data',
'scatter' => 'scatter_plot_data',
'pie' => 'pie_graph_data'}
graph_data = send(graph_method_name[graph_type], scope, id, data_type)
</pre>

:3 Methods complexity
Complex methods were broken down into smaller methods to enhance readability.

== Refactoring in Modules ==

===Code movement===
The modules were initially placed in '''app/models/''' . They were moved to '''/lib/''' folder

===Code Changes===

At many places the developers had added the logic to find, map, get unique object, etc. which already exist in Enumerable module. We changed the code to use these in-built methods. Some of the examples of such changes are:
:1. Code before refactor [self.questionnaire_unique? in assignment_analytic.rb]
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
assignment.questionnaire_types.each do |questionnaire_type|
questionnaire_list = Array.new
assignment.questionnaires.each do |questionnaire|
if questionnaire.type == questionnaire_type
questionnaire_list << questionnaire
end
if questionnaire_list.count > 1
return false
end
end
end
end
return true
end
</pre>

:'''Code after refactoring.''' Here the inbuilt uniq method was used. If there are duplicates, then unique array length will be less than actual length.
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
questionnaires = assignment.questionnaires
return false if questionnaires.uniq { |q| q.type }.length < questionnaires.length
end
return true
end
</pre>

:2. Code before refactoring [ questionnaire_of_type(type_name_in_string) in assignment_analytic.rb ]
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.each do |questionnaire|
if questionnaire.type == type_name_in_string
return questionnaire
end
end
end
</pre>

:'''Code after refactoring:''' The find method was used here.
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.find { |questionnaire| questionnaire == type_name_in_string }
end
</pre>

:3 '''Code before refactoring [average_num_team_reviews in assignment_analytic ]'''. This pattern existed in many classes.
<pre>
def average_num_team_reviews
if num_teams == 0
0
else
total_num_team_reviews.to_f/num_teams
end
end
</pre>

:'''Code after refactoring:'''
<pre>
def average_num_team_reviews
total_num_team_reviews.to_f/num_teams
rescue ZeroDivisionError
0
end
</pre>

The code consisted of several functions with unnecessary complexity. We refactored the code to reduce the complexity. 
The code consisted of several functions that had duplicate code. These methods transformed a list of objects into a list of one of the object’s attributes. This pattern was removed by creating a generic function.
Following was one of the pattern that existed:

<pre>
# Expertiza code before refactoring in assignment_analytic.rb
def team_review_counts
list = Array.new
self.teams.each do |team|
list << team.num_reviews
end
if (list.empty?)
[0]
else
list
end
end
</pre>

The refactored code for the above logic:

<pre>
# Helper function moved to common_analytic.rb
def extract_from_list(list, property)
list.map { |item| item.send(property) }
end

# Method in assignment_analytic.rb
def team_review_counts
extract_from_list self.teams, :num_reviews
(list.empty?) ? [0] : list
end
</pre>

The logic of the method was exactly what the map method does. Futher, a ternary if-else was used to enhance readability.

The above pattern accounted for majority of the duplicate code.
Code before refactoring [self.types in QuestionnaireAnalytic ]
<pre>
def self.types
type_list = Array.new
self.all.each do |questionnaire|
if !type_list.include?(questionnaire.type)
type_list << questionnaire.type
end
end
type_list
end
</pre>

Code after refactoring.
<pre>
def self.types
type_list = extract_from_list self.all, :type
type_list.uniq
end
</pre>

The following is a list of methods and classes changed for refactoring:
#assignment_analytic.rb
##self.questionnaire_unique?
##questionnaire_of_type
##team_review_counts
##team_scores
#course_analytic.rb
##average_num_assignment_teams
##average_assignment_score
##assignment_review_counts
##assignment_team_counts
##assignment_average_scores
##assignment_max_scores
##assignment_min_scores
#assignment_team_analytic.rb
##average_review_word_count
##average_review_score
##average_review_character_count
##review_character_counts
##review_scores
##review_word_counts
#questionnaire_analytic.rb
##questions_text_list
##word_count_list
##character_count_list
#response_analytic.rb
##word_count_list
##character_count_list
##question_score_list
##comments_text_list

= Post-refactoring report=
[[File:code_clime_new.png]]

Here is a summary of the results.

[[File:Report.png]]

=Future work=
#Currently only bar charts can be seen. Further work can be done to get different kinds of graphs such as pie chart, scatter plot, etc.
#There are some requests that take a long time to respond. For example, View Scores Request. They can be optimized to reduce the response time.

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T19:03:50Z

Mknayak: /* Code Changes */

=E818 Refactoring and testing -- analytics=
This Wiki page provides a detailed description of the Open Source Software project conducted on Expertiza, as part of the Object Oriented Languages and Systems coursework.

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is an open source project built using the Ruby on Rails platform. It is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities to manage peer reviews in coursework. The source code can be forked from [https://github.com/expertiza/expertiza github] and cloned for performing modifications. The Expertiza environment is already set up in NC State's VCL image "Ruby on Rails". If you have access, this is quickest way to get a development environment running for Expertiza. See the Expertiza wiki(provide hyperlink) on developing Expertiza on the VCL.

= Overview of project =
===Classes:===
* analytic_controller.rb (163 lines)
* assignment_analytic.rb (206 lines)
* assignment_team_analytic.rb (126 lines)
* course_analytic.rb (142 lines)
* question_analytic.rb (12 lines)
* questionnaire_analytic.rb (55 lines)
* response_analytic.rb (101 lines)
* score_analytic.rb (12 lines)

===What they do:===
Display information about various system components in summary form, to aid in analysis.

===What was done:===
Analytic_controller.rb and course_analytic.rb had much duplicated code, which was be factored out. Additionally, analytic_controller.rb had methods that were too complicated, and were be separated into shorter, well-named methods, to make the operation of the class more transparent. Rest of the modules had duplicate code, which was refactored out.

= Analysis =
We used [https://codeclimate.com/github/expertiza/expertiza/code?q=analytic CodeClimate] to analyse the existing code. As can been be seen, there are several classes with duplicate code, high complexity and code smells. 

[[File:code_clime_old.png]]

*High complexity - AnalyticController, CourseAnalytic, QuestionnaireAnalytic
*Duplication – AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
*Smells - AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
 As regards complexity, along with a high overall complexity, the classes also have a high complexity per method ratio

=Code changes=

==Refactoring in AnalyticController==
:1 Usage of inbuilt methods.
Before
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = Array.new
courses.each do |course|
course_list << [course.name, course.id]
end
respond_to do |format|
format.json { render :json => sort_by_name(course_list) }
end
end
</pre>
 After
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = courses.map { |course| [course.name, course.id] }
render :json => sort_by_name(course_list)
end
</pre>

The above refactoring was applied to team_list and assignment_list as well.

:2 Use of hashes

<pre>
case params[:type]
when "line"
chart_data = line_graph_data(params[:scope], params[:id], params[:data_type])
when "bar"
chart_data = bar_chart_data(params[:scope], params[:id], params[:data_type])
when "scatter"
chart_data = scatter_plot_data(params[:scope], params[:id], params[:data_type])
when "pie"
chart_data = pie_chart_data(params[:scope], params[:id], params[:data_type])
end

</pre>

Hash was used to adhere to the DRY principle.
<pre>
graph_method_name = {'line' => 'line_graph_data',
'bar' => 'bar_chart_data',
'scatter' => 'scatter_plot_data',
'pie' => 'pie_graph_data'}
graph_data = send(graph_method_name[graph_type], scope, id, data_type)
</pre>

:3 Methods complexity
Complex methods were broken down into smaller methods to enhance readability.

== Refactoring in Modules ==

===Code movement===
The modules were initially placed in '''app/models/''' . They were moved to '''/lib/''' folder

===Code Changes===

At many places the developers had added the logic to find, map, get unique object, etc. which already exist in Enumerable module. We changed the code to use these in-built methods. Some of the examples of such changes are:
:1. Code before refactor [self.questionnaire_unique? in assignment_analytic.rb]
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
assignment.questionnaire_types.each do |questionnaire_type|
questionnaire_list = Array.new
assignment.questionnaires.each do |questionnaire|
if questionnaire.type == questionnaire_type
questionnaire_list << questionnaire
end
if questionnaire_list.count > 1
return false
end
end
end
end
return true
end
</pre>

:'''Code after refactoring.''' Here the inbuilt uniq method was used. If there are duplicates, then unique array length will be less than actual length.
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
questionnaires = assignment.questionnaires
return false if questionnaires.uniq { |q| q.type }.length < questionnaires.length
end
return true
end
</pre>

:2. Code before refactoring [ questionnaire_of_type(type_name_in_string) in assignment_analytic.rb ]
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.each do |questionnaire|
if questionnaire.type == type_name_in_string
return questionnaire
end
end
end
</pre>

:'''Code after refactoring:''' The find method was used here.
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.find { |questionnaire| questionnaire == type_name_in_string }
end
</pre>

:3 '''Code before refactoring [average_num_team_reviews in assignment_analytic ]'''. This pattern existed in many classes.
<pre>
def average_num_team_reviews
if num_teams == 0
0
else
total_num_team_reviews.to_f/num_teams
end
end
</pre>

:'''Code after refactoring:'''
<pre>
def average_num_team_reviews
total_num_team_reviews.to_f/num_teams
rescue ZeroDivisionError
0
end
</pre>

The code consisted of several functions with unnecessary complexity. We refactored the code to reduce the complexity. 
The code consisted of several functions that had duplicate code. These methods transformed a list of objects into a list of one of the object’s attributes. This pattern was removed by creating a generic function.
Following was one of the pattern that existed:

<pre>
# Expertiza code before refactoring in assignment_analytic.rb
def team_review_counts
list = Array.new
self.teams.each do |team|
list << team.num_reviews
end
if (list.empty?)
[0]
else
list
end
end
</pre>

The refactored code for the above logic:

<pre>
# Helper function moved to common_analytic.rb
def extract_from_list(list, property)
list.map { |item| item.send(property) }
end

# Method in assignment_analytic.rb
def team_review_counts
extract_from_list self.teams, :num_reviews
(list.empty?) ? [0] : list
end
</pre>

The logic of the method was exactly what the map method does. Futher, a ternary if-else was used to enhance readability.

The above pattern accounted for majority of the duplicate code.
Code before refactoring [self.types in QuestionnaireAnalytic ]
<pre>
def self.types
type_list = Array.new
self.all.each do |questionnaire|
if !type_list.include?(questionnaire.type)
type_list << questionnaire.type
end
end
type_list
end
</pre>

Code after refactoring.
<pre>
def self.types
type_list = extract_from_list self.all, :type
type_list.uniq
end
</pre>

The following is a list of methods and classes changed for refactoring:
#assignment_analytic.rb
##self.questionnaire_unique?
##questionnaire_of_type
##team_review_counts
##team_scores
#course_analytic.rb
##average_num_assignment_teams
##average_assignment_score
##assignment_review_counts
##assignment_team_counts
##assignment_average_scores
##assignment_max_scores
##assignment_min_scores
#assignment_team_analytic.rb
##average_review_word_count
##average_review_score
##average_review_character_count
##review_character_counts
##review_scores
##review_word_counts
#questionnaire_analytic.rb
##questions_text_list
##word_count_list
##character_count_list
#response_analytic.rb
##word_count_list
##character_count_list
##question_score_list
##comments_text_list

= Post-refactoring report=
[[File:code_clime_new.png]]

Here is a summary of the results.

[[File:Report.png]]

=Future work=
#Currently only bar charts can be seen. Further work can be done to get different kinds of graphs such as pie chart, scatter plot, etc.
#There are some requests that take a long time to respond. For example, View Scores Request. They can be optimized to reduce the response time.

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T19:00:46Z

Mknayak: /* Code Changes */

=E818 Refactoring and testing -- analytics=
This Wiki page provides a detailed description of the Open Source Software project conducted on Expertiza, as part of the Object Oriented Languages and Systems coursework.

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is an open source project built using the Ruby on Rails platform. It is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities to manage peer reviews in coursework. The source code can be forked from [https://github.com/expertiza/expertiza github] and cloned for performing modifications. The Expertiza environment is already set up in NC State's VCL image "Ruby on Rails". If you have access, this is quickest way to get a development environment running for Expertiza. See the Expertiza wiki(provide hyperlink) on developing Expertiza on the VCL.

= Overview of project =
===Classes:===
* analytic_controller.rb (163 lines)
* assignment_analytic.rb (206 lines)
* assignment_team_analytic.rb (126 lines)
* course_analytic.rb (142 lines)
* question_analytic.rb (12 lines)
* questionnaire_analytic.rb (55 lines)
* response_analytic.rb (101 lines)
* score_analytic.rb (12 lines)

===What they do:===
Display information about various system components in summary form, to aid in analysis.

===What was done:===
Analytic_controller.rb and course_analytic.rb had much duplicated code, which was be factored out. Additionally, analytic_controller.rb had methods that were too complicated, and were be separated into shorter, well-named methods, to make the operation of the class more transparent. Rest of the modules had duplicate code, which was refactored out.

= Analysis =
We used [https://codeclimate.com/github/expertiza/expertiza/code?q=analytic CodeClimate] to analyse the existing code. As can been be seen, there are several classes with duplicate code, high complexity and code smells. 

[[File:code_clime_old.png]]

*High complexity - AnalyticController, CourseAnalytic, QuestionnaireAnalytic
*Duplication – AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
*Smells - AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
 As regards complexity, along with a high overall complexity, the classes also have a high complexity per method ratio

=Code changes=

==Refactoring in AnalyticController==
:1 Usage of inbuilt methods.
Before
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = Array.new
courses.each do |course|
course_list << [course.name, course.id]
end
respond_to do |format|
format.json { render :json => sort_by_name(course_list) }
end
end
</pre>
 After
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = courses.map { |course| [course.name, course.id] }
render :json => sort_by_name(course_list)
end
</pre>

The above refactoring was applied to team_list and assignment_list as well.

:2 Use of hashes

<pre>
case params[:type]
when "line"
chart_data = line_graph_data(params[:scope], params[:id], params[:data_type])
when "bar"
chart_data = bar_chart_data(params[:scope], params[:id], params[:data_type])
when "scatter"
chart_data = scatter_plot_data(params[:scope], params[:id], params[:data_type])
when "pie"
chart_data = pie_chart_data(params[:scope], params[:id], params[:data_type])
end

</pre>

Hash was used to adhere to the DRY principle.
<pre>
graph_method_name = {'line' => 'line_graph_data',
'bar' => 'bar_chart_data',
'scatter' => 'scatter_plot_data',
'pie' => 'pie_graph_data'}
graph_data = send(graph_method_name[graph_type], scope, id, data_type)
</pre>

:3 Methods complexity
Complex methods were broken down into smaller methods to enhance readability.

== Refactoring in Modules ==

===Code movement===
The modules were initially placed in '''app/models/''' . They were moved to '''/lib/''' folder

===Code Changes===

At many places the developers had added the logic to find, map, get unique object, etc. which already exist in Enumerable module. We changed the code to use these in-built methods. Some of the examples of such changes are:
:1. Code before refactor [self.questionnaire_unique? in assignment_analytic.rb]
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
assignment.questionnaire_types.each do |questionnaire_type|
questionnaire_list = Array.new
assignment.questionnaires.each do |questionnaire|
if questionnaire.type == questionnaire_type
questionnaire_list << questionnaire
end
if questionnaire_list.count > 1
return false
end
end
end
end
return true
end
</pre>

:'''Code after refactoring.''' Here the inbuilt uniq method was used. If there are duplicates, then unique array length will be less than actual length.
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
questionnaires = assignment.questionnaires
return false if questionnaires.uniq { |q| q.type }.length < questionnaires.length
end
return true
end
</pre>

:2. Code before refactoring [ questionnaire_of_type(type_name_in_string) in assignment_analytic.rb ]
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.each do |questionnaire|
if questionnaire.type == type_name_in_string
return questionnaire
end
end
end
</pre>

'''Code after refactoring:''' The find method was used here.
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.find { |questionnaire| questionnaire == type_name_in_string }
end
</pre>

:3 Code before refactoring [average_num_team_reviews in assignment_analytic ]. This pattern existed in many classes.
<pre>
def average_num_team_reviews
if num_teams == 0
0
else
total_num_team_reviews.to_f/num_teams
end
end
</pre>
:'''Code after refactoring:'''
<pre>
def average_num_team_reviews
total_num_team_reviews.to_f/num_teams
rescue ZeroDivisionError
0
end
</pre>

The code consisted of several functions with unnecessary complexity. We refactored the code to reduce the complexity. 
The code consisted of several functions that had duplicate code. These methods transformed a list of objects into a list of one of the object’s attributes. This pattern was removed by creating a generic function.
Following was one of the pattern that existed:

<pre>
# Expertiza code before refactoring in assignment_analytic.rb
def team_review_counts
list = Array.new
self.teams.each do |team|
list << team.num_reviews
end
if (list.empty?)
[0]
else
list
end
end
</pre>

The refactored code for the above logic:

<pre>
# Helper function moved to common_analytic.rb
def extract_from_list(list, property)
list.map { |item| item.send(property) }
end

# Method in assignment_analytic.rb
def team_review_counts
extract_from_list self.teams, :num_reviews
(list.empty?) ? [0] : list
end
</pre>

The logic of the method was exactly what the map method does. Futher, a ternary if-else was used to enhance readability.

The above pattern accounted for majority of the duplicate code.
Code before refactoring [self.types in QuestionnaireAnalytic ]
<pre>
def self.types
type_list = Array.new
self.all.each do |questionnaire|
if !type_list.include?(questionnaire.type)
type_list << questionnaire.type
end
end
type_list
end
</pre>

Code after refactoring.
<pre>
def self.types
type_list = extract_from_list self.all, :type
type_list.uniq
end
</pre>

The following is a list of methods and classes changed for refactoring:
#assignment_analytic.rb
##self.questionnaire_unique?
##questionnaire_of_type
##team_review_counts
##team_scores
#course_analytic.rb
##average_num_assignment_teams
##average_assignment_score
##assignment_review_counts
##assignment_team_counts
##assignment_average_scores
##assignment_max_scores
##assignment_min_scores
#assignment_team_analytic.rb
##average_review_word_count
##average_review_score
##average_review_character_count
##review_character_counts
##review_scores
##review_word_counts
#questionnaire_analytic.rb
##questions_text_list
##word_count_list
##character_count_list
#response_analytic.rb
##word_count_list
##character_count_list
##question_score_list
##comments_text_list

= Post-refactoring report=
[[File:code_clime_new.png]]

Here is a summary of the results.

[[File:Report.png]]

=Future work=
#Currently only bar charts can be seen. Further work can be done to get different kinds of graphs such as pie chart, scatter plot, etc.
#There are some requests that take a long time to respond. For example, View Scores Request. They can be optimized to reduce the response time.

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T18:59:15Z

Mknayak: /* Code Changes */

=E818 Refactoring and testing -- analytics=
This Wiki page provides a detailed description of the Open Source Software project conducted on Expertiza, as part of the Object Oriented Languages and Systems coursework.

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is an open source project built using the Ruby on Rails platform. It is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities to manage peer reviews in coursework. The source code can be forked from [https://github.com/expertiza/expertiza github] and cloned for performing modifications. The Expertiza environment is already set up in NC State's VCL image "Ruby on Rails". If you have access, this is quickest way to get a development environment running for Expertiza. See the Expertiza wiki(provide hyperlink) on developing Expertiza on the VCL.

= Overview of project =
===Classes:===
* analytic_controller.rb (163 lines)
* assignment_analytic.rb (206 lines)
* assignment_team_analytic.rb (126 lines)
* course_analytic.rb (142 lines)
* question_analytic.rb (12 lines)
* questionnaire_analytic.rb (55 lines)
* response_analytic.rb (101 lines)
* score_analytic.rb (12 lines)

===What they do:===
Display information about various system components in summary form, to aid in analysis.

===What was done:===
Analytic_controller.rb and course_analytic.rb had much duplicated code, which was be factored out. Additionally, analytic_controller.rb had methods that were too complicated, and were be separated into shorter, well-named methods, to make the operation of the class more transparent. Rest of the modules had duplicate code, which was refactored out.

= Analysis =
We used [https://codeclimate.com/github/expertiza/expertiza/code?q=analytic CodeClimate] to analyse the existing code. As can been be seen, there are several classes with duplicate code, high complexity and code smells. 

[[File:code_clime_old.png]]

*High complexity - AnalyticController, CourseAnalytic, QuestionnaireAnalytic
*Duplication – AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
*Smells - AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
 As regards complexity, along with a high overall complexity, the classes also have a high complexity per method ratio

=Code changes=

==Refactoring in AnalyticController==
:1 Usage of inbuilt methods.
Before
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = Array.new
courses.each do |course|
course_list << [course.name, course.id]
end
respond_to do |format|
format.json { render :json => sort_by_name(course_list) }
end
end
</pre>
 After
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = courses.map { |course| [course.name, course.id] }
render :json => sort_by_name(course_list)
end
</pre>

The above refactoring was applied to team_list and assignment_list as well.

:2 Use of hashes

<pre>
case params[:type]
when "line"
chart_data = line_graph_data(params[:scope], params[:id], params[:data_type])
when "bar"
chart_data = bar_chart_data(params[:scope], params[:id], params[:data_type])
when "scatter"
chart_data = scatter_plot_data(params[:scope], params[:id], params[:data_type])
when "pie"
chart_data = pie_chart_data(params[:scope], params[:id], params[:data_type])
end

</pre>

Hash was used to adhere to the DRY principle.
<pre>
graph_method_name = {'line' => 'line_graph_data',
'bar' => 'bar_chart_data',
'scatter' => 'scatter_plot_data',
'pie' => 'pie_graph_data'}
graph_data = send(graph_method_name[graph_type], scope, id, data_type)
</pre>

:3 Methods complexity
Complex methods were broken down into smaller methods to enhance readability.

== Refactoring in Modules ==

===Code movement===
The modules were initially placed in '''app/models/''' . They were moved to '''/lib/''' folder

===Code Changes===

At many places the developers had added the logic to find, map, get unique object, etc. which already exist in Enumerable module. We changed the code to use these in-built methods. Some of the examples of such changes are:
:1. Code before refactor [self.questionnaire_unique? in assignment_analytic.rb]
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
assignment.questionnaire_types.each do |questionnaire_type|
questionnaire_list = Array.new
assignment.questionnaires.each do |questionnaire|
if questionnaire.type == questionnaire_type
questionnaire_list << questionnaire
end
if questionnaire_list.count > 1
return false
end
end
end
end
return true
end
</pre>

Code after refactoring. Here the inbuilt uniq method was used. If there are duplicates, then unique array length will be less than actual length.
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
questionnaires = assignment.questionnaires
return false if questionnaires.uniq { |q| q.type }.length < questionnaires.length
end
return true
end
</pre>

:2. Code before refactoring [ questionnaire_of_type(type_name_in_string) in assignment_analytic.rb ]
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.each do |questionnaire|
if questionnaire.type == type_name_in_string
return questionnaire
end
end
end
</pre>

Code after refactoring. The find method was used here.
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.find { |questionnaire| questionnaire == type_name_in_string }
end
</pre>

:3 Code before refactoring [average_num_team_reviews in assignment_analytic ]. This pattern existed in many classes.
<pre>
def average_num_team_reviews
if num_teams == 0
0
else
total_num_team_reviews.to_f/num_teams
end
end
</pre>
Code after refactoring.
<pre>
def average_num_team_reviews
total_num_team_reviews.to_f/num_teams
rescue ZeroDivisionError
0
end
</pre>

The code consisted of several functions with unnecessary complexity. We refactored the code to reduce the complexity.
The code consisted of several functions that had duplicate code. These methods transformed a list of objects into a list of one of the object’s attributes. This pattern was removed by creating a generic function.
Following was one of the pattern that existed:

<pre>
# Expertiza code before refactoring in assignment_analytic.rb
def team_review_counts
list = Array.new
self.teams.each do |team|
list << team.num_reviews
end
if (list.empty?)
[0]
else
list
end
end
</pre>

The refactored code for the above logic:

<pre>
# Helper function moved to common_analytic.rb
def extract_from_list(list, property)
list.map { |item| item.send(property) }
end

# Method in assignment_analytic.rb
def team_review_counts
extract_from_list self.teams, :num_reviews
(list.empty?) ? [0] : list
end
</pre>

The logic of the method was exactly what the map method does. Futher, a ternary if-else was used to enhance readability.

The above pattern accounted for majority of the duplicate code.
Code before refactoring [self.types in QuestionnaireAnalytic ]
<pre>
def self.types
type_list = Array.new
self.all.each do |questionnaire|
if !type_list.include?(questionnaire.type)
type_list << questionnaire.type
end
end
type_list
end
</pre>

Code after refactoring.
<pre>
def self.types
type_list = extract_from_list self.all, :type
type_list.uniq
end
</pre>

The following is a list of methods and classes changed for refactoring:
#assignment_analytic.rb
##self.questionnaire_unique?
##questionnaire_of_type
##team_review_counts
##team_scores
#course_analytic.rb
##average_num_assignment_teams
##average_assignment_score
##assignment_review_counts
##assignment_team_counts
##assignment_average_scores
##assignment_max_scores
##assignment_min_scores
#assignment_team_analytic.rb
##average_review_word_count
##average_review_score
##average_review_character_count
##review_character_counts
##review_scores
##review_word_counts
#questionnaire_analytic.rb
##questions_text_list
##word_count_list
##character_count_list
#response_analytic.rb
##word_count_list
##character_count_list
##question_score_list
##comments_text_list

= Post-refactoring report=
[[File:code_clime_new.png]]

Here is a summary of the results.

[[File:Report.png]]

=Future work=
#Currently only bar charts can be seen. Further work can be done to get different kinds of graphs such as pie chart, scatter plot, etc.
#There are some requests that take a long time to respond. For example, View Scores Request. They can be optimized to reduce the response time.

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T18:58:46Z

Mknayak: /* Code Changes */

=E818 Refactoring and testing -- analytics=
This Wiki page provides a detailed description of the Open Source Software project conducted on Expertiza, as part of the Object Oriented Languages and Systems coursework.

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is an open source project built using the Ruby on Rails platform. It is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities to manage peer reviews in coursework. The source code can be forked from [https://github.com/expertiza/expertiza github] and cloned for performing modifications. The Expertiza environment is already set up in NC State's VCL image "Ruby on Rails". If you have access, this is quickest way to get a development environment running for Expertiza. See the Expertiza wiki(provide hyperlink) on developing Expertiza on the VCL.

= Overview of project =
===Classes:===
* analytic_controller.rb (163 lines)
* assignment_analytic.rb (206 lines)
* assignment_team_analytic.rb (126 lines)
* course_analytic.rb (142 lines)
* question_analytic.rb (12 lines)
* questionnaire_analytic.rb (55 lines)
* response_analytic.rb (101 lines)
* score_analytic.rb (12 lines)

===What they do:===
Display information about various system components in summary form, to aid in analysis.

===What was done:===
Analytic_controller.rb and course_analytic.rb had much duplicated code, which was be factored out. Additionally, analytic_controller.rb had methods that were too complicated, and were be separated into shorter, well-named methods, to make the operation of the class more transparent. Rest of the modules had duplicate code, which was refactored out.

= Analysis =
We used [https://codeclimate.com/github/expertiza/expertiza/code?q=analytic CodeClimate] to analyse the existing code. As can been be seen, there are several classes with duplicate code, high complexity and code smells. 

[[File:code_clime_old.png]]

*High complexity - AnalyticController, CourseAnalytic, QuestionnaireAnalytic
*Duplication – AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
*Smells - AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
 As regards complexity, along with a high overall complexity, the classes also have a high complexity per method ratio

=Code changes=

==Refactoring in AnalyticController==
:1 Usage of inbuilt methods.
Before
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = Array.new
courses.each do |course|
course_list << [course.name, course.id]
end
respond_to do |format|
format.json { render :json => sort_by_name(course_list) }
end
end
</pre>
 After
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = courses.map { |course| [course.name, course.id] }
render :json => sort_by_name(course_list)
end
</pre>

The above refactoring was applied to team_list and assignment_list as well.

:2 Use of hashes

<pre>
case params[:type]
when "line"
chart_data = line_graph_data(params[:scope], params[:id], params[:data_type])
when "bar"
chart_data = bar_chart_data(params[:scope], params[:id], params[:data_type])
when "scatter"
chart_data = scatter_plot_data(params[:scope], params[:id], params[:data_type])
when "pie"
chart_data = pie_chart_data(params[:scope], params[:id], params[:data_type])
end

</pre>

Hash was used to adhere to the DRY principle.
<pre>
graph_method_name = {'line' => 'line_graph_data',
'bar' => 'bar_chart_data',
'scatter' => 'scatter_plot_data',
'pie' => 'pie_graph_data'}
graph_data = send(graph_method_name[graph_type], scope, id, data_type)
</pre>

:3 Methods complexity
Complex methods were broken down into smaller methods to enhance readability.

== Refactoring in Modules ==

===Code movement===
The modules were initially placed in '''app/models/''' . They were moved to '''/lib/''' folder

===Code Changes===

At many places the developers had added the logic to find, map, get unique object, etc. which already exist in Enumerable module. We changed the code to use these in-built methods. Some of the examples of such changes are:
:1. Code before refactor [self.questionnaire_unique? in assignment_analytic.rb]
:<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
assignment.questionnaire_types.each do |questionnaire_type|
questionnaire_list = Array.new
assignment.questionnaires.each do |questionnaire|
if questionnaire.type == questionnaire_type
questionnaire_list << questionnaire
end
if questionnaire_list.count > 1
return false
end
end
end
end
return true
end
</pre>

Code after refactoring. Here the inbuilt uniq method was used. If there are duplicates, then unique array length will be less than actual length.
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
questionnaires = assignment.questionnaires
return false if questionnaires.uniq { |q| q.type }.length < questionnaires.length
end
return true
end
</pre>

:2. Code before refactoring [ questionnaire_of_type(type_name_in_string) in assignment_analytic.rb ]
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.each do |questionnaire|
if questionnaire.type == type_name_in_string
return questionnaire
end
end
end
</pre>

Code after refactoring. The find method was used here.
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.find { |questionnaire| questionnaire == type_name_in_string }
end
</pre>

:3 Code before refactoring [average_num_team_reviews in assignment_analytic ]. This pattern existed in many classes.
<pre>
def average_num_team_reviews
if num_teams == 0
0
else
total_num_team_reviews.to_f/num_teams
end
end
</pre>
Code after refactoring.
<pre>
def average_num_team_reviews
total_num_team_reviews.to_f/num_teams
rescue ZeroDivisionError
0
end
</pre>

The code consisted of several functions with unnecessary complexity. We refactored the code to reduce the complexity.
The code consisted of several functions that had duplicate code. These methods transformed a list of objects into a list of one of the object’s attributes. This pattern was removed by creating a generic function.
Following was one of the pattern that existed:

<pre>
# Expertiza code before refactoring in assignment_analytic.rb
def team_review_counts
list = Array.new
self.teams.each do |team|
list << team.num_reviews
end
if (list.empty?)
[0]
else
list
end
end
</pre>

The refactored code for the above logic:

<pre>
# Helper function moved to common_analytic.rb
def extract_from_list(list, property)
list.map { |item| item.send(property) }
end

# Method in assignment_analytic.rb
def team_review_counts
extract_from_list self.teams, :num_reviews
(list.empty?) ? [0] : list
end
</pre>

The logic of the method was exactly what the map method does. Futher, a ternary if-else was used to enhance readability.

The above pattern accounted for majority of the duplicate code.
Code before refactoring [self.types in QuestionnaireAnalytic ]
<pre>
def self.types
type_list = Array.new
self.all.each do |questionnaire|
if !type_list.include?(questionnaire.type)
type_list << questionnaire.type
end
end
type_list
end
</pre>

Code after refactoring.
<pre>
def self.types
type_list = extract_from_list self.all, :type
type_list.uniq
end
</pre>

The following is a list of methods and classes changed for refactoring:
#assignment_analytic.rb
##self.questionnaire_unique?
##questionnaire_of_type
##team_review_counts
##team_scores
#course_analytic.rb
##average_num_assignment_teams
##average_assignment_score
##assignment_review_counts
##assignment_team_counts
##assignment_average_scores
##assignment_max_scores
##assignment_min_scores
#assignment_team_analytic.rb
##average_review_word_count
##average_review_score
##average_review_character_count
##review_character_counts
##review_scores
##review_word_counts
#questionnaire_analytic.rb
##questions_text_list
##word_count_list
##character_count_list
#response_analytic.rb
##word_count_list
##character_count_list
##question_score_list
##comments_text_list

= Post-refactoring report=
[[File:code_clime_new.png]]

Here is a summary of the results.

[[File:Report.png]]

=Future work=
#Currently only bar charts can be seen. Further work can be done to get different kinds of graphs such as pie chart, scatter plot, etc.
#There are some requests that take a long time to respond. For example, View Scores Request. They can be optimized to reduce the response time.

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T18:58:17Z

Mknayak: /* Refactoring in Modules */

=E818 Refactoring and testing -- analytics=
This Wiki page provides a detailed description of the Open Source Software project conducted on Expertiza, as part of the Object Oriented Languages and Systems coursework.

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is an open source project built using the Ruby on Rails platform. It is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities to manage peer reviews in coursework. The source code can be forked from [https://github.com/expertiza/expertiza github] and cloned for performing modifications. The Expertiza environment is already set up in NC State's VCL image "Ruby on Rails". If you have access, this is quickest way to get a development environment running for Expertiza. See the Expertiza wiki(provide hyperlink) on developing Expertiza on the VCL.

= Overview of project =
===Classes:===
* analytic_controller.rb (163 lines)
* assignment_analytic.rb (206 lines)
* assignment_team_analytic.rb (126 lines)
* course_analytic.rb (142 lines)
* question_analytic.rb (12 lines)
* questionnaire_analytic.rb (55 lines)
* response_analytic.rb (101 lines)
* score_analytic.rb (12 lines)

===What they do:===
Display information about various system components in summary form, to aid in analysis.

===What was done:===
Analytic_controller.rb and course_analytic.rb had much duplicated code, which was be factored out. Additionally, analytic_controller.rb had methods that were too complicated, and were be separated into shorter, well-named methods, to make the operation of the class more transparent. Rest of the modules had duplicate code, which was refactored out.

= Analysis =
We used [https://codeclimate.com/github/expertiza/expertiza/code?q=analytic CodeClimate] to analyse the existing code. As can been be seen, there are several classes with duplicate code, high complexity and code smells. 

[[File:code_clime_old.png]]

*High complexity - AnalyticController, CourseAnalytic, QuestionnaireAnalytic
*Duplication – AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
*Smells - AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
 As regards complexity, along with a high overall complexity, the classes also have a high complexity per method ratio

=Code changes=

==Refactoring in AnalyticController==
:1 Usage of inbuilt methods.
Before
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = Array.new
courses.each do |course|
course_list << [course.name, course.id]
end
respond_to do |format|
format.json { render :json => sort_by_name(course_list) }
end
end
</pre>
 After
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = courses.map { |course| [course.name, course.id] }
render :json => sort_by_name(course_list)
end
</pre>

The above refactoring was applied to team_list and assignment_list as well.

:2 Use of hashes

<pre>
case params[:type]
when "line"
chart_data = line_graph_data(params[:scope], params[:id], params[:data_type])
when "bar"
chart_data = bar_chart_data(params[:scope], params[:id], params[:data_type])
when "scatter"
chart_data = scatter_plot_data(params[:scope], params[:id], params[:data_type])
when "pie"
chart_data = pie_chart_data(params[:scope], params[:id], params[:data_type])
end

</pre>

Hash was used to adhere to the DRY principle.
<pre>
graph_method_name = {'line' => 'line_graph_data',
'bar' => 'bar_chart_data',
'scatter' => 'scatter_plot_data',
'pie' => 'pie_graph_data'}
graph_data = send(graph_method_name[graph_type], scope, id, data_type)
</pre>

:3 Methods complexity
Complex methods were broken down into smaller methods to enhance readability.

== Refactoring in Modules ==

===Code movement===
The modules were initially placed in '''app/models/''' . They were moved to '''/lib/''' folder

===Code Changes===

:At many places the developers had added the logic to find, map, get unique object, etc. which already exist in Enumerable module. We changed the code to use these in-built methods. Some of the examples of such changes are:
:1. Code before refactor [self.questionnaire_unique? in assignment_analytic.rb]
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
assignment.questionnaire_types.each do |questionnaire_type|
questionnaire_list = Array.new
assignment.questionnaires.each do |questionnaire|
if questionnaire.type == questionnaire_type
questionnaire_list << questionnaire
end
if questionnaire_list.count > 1
return false
end
end
end
end
return true
end
</pre>

Code after refactoring. Here the inbuilt uniq method was used. If there are duplicates, then unique array length will be less than actual length.
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
questionnaires = assignment.questionnaires
return false if questionnaires.uniq { |q| q.type }.length < questionnaires.length
end
return true
end
</pre>

:2. Code before refactoring [ questionnaire_of_type(type_name_in_string) in assignment_analytic.rb ]
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.each do |questionnaire|
if questionnaire.type == type_name_in_string
return questionnaire
end
end
end
</pre>

Code after refactoring. The find method was used here.
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.find { |questionnaire| questionnaire == type_name_in_string }
end
</pre>

:3 Code before refactoring [average_num_team_reviews in assignment_analytic ]. This pattern existed in many classes.
<pre>
def average_num_team_reviews
if num_teams == 0
0
else
total_num_team_reviews.to_f/num_teams
end
end
</pre>
Code after refactoring.
<pre>
def average_num_team_reviews
total_num_team_reviews.to_f/num_teams
rescue ZeroDivisionError
0
end
</pre>

The code consisted of several functions with unnecessary complexity. We refactored the code to reduce the complexity.
The code consisted of several functions that had duplicate code. These methods transformed a list of objects into a list of one of the object’s attributes. This pattern was removed by creating a generic function.
Following was one of the pattern that existed:

<pre>
# Expertiza code before refactoring in assignment_analytic.rb
def team_review_counts
list = Array.new
self.teams.each do |team|
list << team.num_reviews
end
if (list.empty?)
[0]
else
list
end
end
</pre>

The refactored code for the above logic:

<pre>
# Helper function moved to common_analytic.rb
def extract_from_list(list, property)
list.map { |item| item.send(property) }
end

# Method in assignment_analytic.rb
def team_review_counts
extract_from_list self.teams, :num_reviews
(list.empty?) ? [0] : list
end
</pre>

The logic of the method was exactly what the map method does. Futher, a ternary if-else was used to enhance readability.

The above pattern accounted for majority of the duplicate code.
Code before refactoring [self.types in QuestionnaireAnalytic ]
<pre>
def self.types
type_list = Array.new
self.all.each do |questionnaire|
if !type_list.include?(questionnaire.type)
type_list << questionnaire.type
end
end
type_list
end
</pre>

Code after refactoring.
<pre>
def self.types
type_list = extract_from_list self.all, :type
type_list.uniq
end
</pre>

The following is a list of methods and classes changed for refactoring:
#assignment_analytic.rb
##self.questionnaire_unique?
##questionnaire_of_type
##team_review_counts
##team_scores
#course_analytic.rb
##average_num_assignment_teams
##average_assignment_score
##assignment_review_counts
##assignment_team_counts
##assignment_average_scores
##assignment_max_scores
##assignment_min_scores
#assignment_team_analytic.rb
##average_review_word_count
##average_review_score
##average_review_character_count
##review_character_counts
##review_scores
##review_word_counts
#questionnaire_analytic.rb
##questions_text_list
##word_count_list
##character_count_list
#response_analytic.rb
##word_count_list
##character_count_list
##question_score_list
##comments_text_list

= Post-refactoring report=
[[File:code_clime_new.png]]

Here is a summary of the results.

[[File:Report.png]]

=Future work=
#Currently only bar charts can be seen. Further work can be done to get different kinds of graphs such as pie chart, scatter plot, etc.
#There are some requests that take a long time to respond. For example, View Scores Request. They can be optimized to reduce the response time.

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T18:53:28Z

Mknayak: /* Refactoring in AnalyticController */

=E818 Refactoring and testing -- analytics=
This Wiki page provides a detailed description of the Open Source Software project conducted on Expertiza, as part of the Object Oriented Languages and Systems coursework.

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is an open source project built using the Ruby on Rails platform. It is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities to manage peer reviews in coursework. The source code can be forked from [https://github.com/expertiza/expertiza github] and cloned for performing modifications. The Expertiza environment is already set up in NC State's VCL image "Ruby on Rails". If you have access, this is quickest way to get a development environment running for Expertiza. See the Expertiza wiki(provide hyperlink) on developing Expertiza on the VCL.

= Overview of project =
===Classes:===
* analytic_controller.rb (163 lines)
* assignment_analytic.rb (206 lines)
* assignment_team_analytic.rb (126 lines)
* course_analytic.rb (142 lines)
* question_analytic.rb (12 lines)
* questionnaire_analytic.rb (55 lines)
* response_analytic.rb (101 lines)
* score_analytic.rb (12 lines)

===What they do:===
Display information about various system components in summary form, to aid in analysis.

===What was done:===
Analytic_controller.rb and course_analytic.rb had much duplicated code, which was be factored out. Additionally, analytic_controller.rb had methods that were too complicated, and were be separated into shorter, well-named methods, to make the operation of the class more transparent. Rest of the modules had duplicate code, which was refactored out.

= Analysis =
We used [https://codeclimate.com/github/expertiza/expertiza/code?q=analytic CodeClimate] to analyse the existing code. As can been be seen, there are several classes with duplicate code, high complexity and code smells. 

[[File:code_clime_old.png]]

*High complexity - AnalyticController, CourseAnalytic, QuestionnaireAnalytic
*Duplication – AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
*Smells - AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
 As regards complexity, along with a high overall complexity, the classes also have a high complexity per method ratio

=Code changes=

==Refactoring in AnalyticController==
:1 Usage of inbuilt methods.
Before
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = Array.new
courses.each do |course|
course_list << [course.name, course.id]
end
respond_to do |format|
format.json { render :json => sort_by_name(course_list) }
end
end
</pre>
 After
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = courses.map { |course| [course.name, course.id] }
render :json => sort_by_name(course_list)
end
</pre>

The above refactoring was applied to team_list and assignment_list as well.

:2 Use of hashes

<pre>
case params[:type]
when "line"
chart_data = line_graph_data(params[:scope], params[:id], params[:data_type])
when "bar"
chart_data = bar_chart_data(params[:scope], params[:id], params[:data_type])
when "scatter"
chart_data = scatter_plot_data(params[:scope], params[:id], params[:data_type])
when "pie"
chart_data = pie_chart_data(params[:scope], params[:id], params[:data_type])
end

</pre>

Hash was used to adhere to the DRY principle.
<pre>
graph_method_name = {'line' => 'line_graph_data',
'bar' => 'bar_chart_data',
'scatter' => 'scatter_plot_data',
'pie' => 'pie_graph_data'}
graph_data = send(graph_method_name[graph_type], scope, id, data_type)
</pre>

:3 Methods complexity
Complex methods were broken down into smaller methods to enhance readability.

== Refactoring in Modules ==

At many places the developers had added the logic to find, map, get unique object, etc. which already exist in Enumerable module. We changed the code to use these in-built methods. Some of the examples of such changes are:
:1. Code before refactor [self.questionnaire_unique? in assignment_analytic.rb]
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
assignment.questionnaire_types.each do |questionnaire_type|
questionnaire_list = Array.new
assignment.questionnaires.each do |questionnaire|
if questionnaire.type == questionnaire_type
questionnaire_list << questionnaire
end
if questionnaire_list.count > 1
return false
end
end
end
end
return true
end
</pre>

Code after refactoring. Here the inbuilt uniq method was used. If there are duplicates, then unique array length will be less than actual length.
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
questionnaires = assignment.questionnaires
return false if questionnaires.uniq { |q| q.type }.length < questionnaires.length
end
return true
end
</pre>

:2. Code before refactoring [ questionnaire_of_type(type_name_in_string) in assignment_analytic.rb ]
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.each do |questionnaire|
if questionnaire.type == type_name_in_string
return questionnaire
end
end
end
</pre>

Code after refactoring. The find method was used here.
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.find { |questionnaire| questionnaire == type_name_in_string }
end
</pre>

:3 Code before refactoring [average_num_team_reviews in assignment_analytic ]. This pattern existed in many classes.
<pre>
def average_num_team_reviews
if num_teams == 0
0
else
total_num_team_reviews.to_f/num_teams
end
end
</pre>
Code after refactoring.
<pre>
def average_num_team_reviews
total_num_team_reviews.to_f/num_teams
rescue ZeroDivisionError
0
end
</pre>

The code consisted of several functions with unnecessary complexity. We refactored the code to reduce the complexity.
The code consisted of several functions that had duplicate code. These methods transformed a list of objects into a list of one of the object’s attributes. This pattern was removed by creating a generic function.
Following was one of the pattern that existed:

<pre>
# Expertiza code before refactoring in assignment_analytic.rb
def team_review_counts
list = Array.new
self.teams.each do |team|
list << team.num_reviews
end
if (list.empty?)
[0]
else
list
end
end
</pre>

The refactored code for the above logic:

<pre>
# Helper function moved to common_analytic.rb
def extract_from_list(list, property)
list.map { |item| item.send(property) }
end

# Method in assignment_analytic.rb
def team_review_counts
extract_from_list self.teams, :num_reviews
(list.empty?) ? [0] : list
end
</pre>

The logic of the method was exactly what the map method does. Futher, a ternary if-else was used to enhance readability.

The above pattern accounted for majority of the duplicate code.
Code before refactoring [self.types in QuestionnaireAnalytic ]
<pre>
def self.types
type_list = Array.new
self.all.each do |questionnaire|
if !type_list.include?(questionnaire.type)
type_list << questionnaire.type
end
end
type_list
end
</pre>

Code after refactoring.
<pre>
def self.types
type_list = extract_from_list self.all, :type
type_list.uniq
end
</pre>

The following is a list of methods and classes changed for refactoring:
#assignment_analytic.rb
##self.questionnaire_unique?
##questionnaire_of_type
##team_review_counts
##team_scores
#course_analytic.rb
##average_num_assignment_teams
##average_assignment_score
##assignment_review_counts
##assignment_team_counts
##assignment_average_scores
##assignment_max_scores
##assignment_min_scores
#assignment_team_analytic.rb
##average_review_word_count
##average_review_score
##average_review_character_count
##review_character_counts
##review_scores
##review_word_counts
#questionnaire_analytic.rb
##questions_text_list
##word_count_list
##character_count_list
#response_analytic.rb
##word_count_list
##character_count_list
##question_score_list
##comments_text_list

= Post-refactoring report=
[[File:code_clime_new.png]]

Here is a summary of the results.

[[File:Report.png]]

=Future work=
#Currently only bar charts can be seen. Further work can be done to get different kinds of graphs such as pie chart, scatter plot, etc.
#There are some requests that take a long time to respond. For example, View Scores Request. They can be optimized to reduce the response time.

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T18:26:15Z

Mknayak: /* Code changes */

=E818 Refactoring and testing -- analytics=
This Wiki page provides a detailed description of the Open Source Software project conducted on Expertiza, as part of the Object Oriented Languages and Systems coursework.

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is an open source project built using the Ruby on Rails platform. It is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities to manage peer reviews in coursework. The source code can be forked from [https://github.com/expertiza/expertiza github] and cloned for performing modifications. The Expertiza environment is already set up in NC State's VCL image "Ruby on Rails". If you have access, this is quickest way to get a development environment running for Expertiza. See the Expertiza wiki(provide hyperlink) on developing Expertiza on the VCL.

= Overview of project =
===Classes:===
* analytic_controller.rb (163 lines)
* assignment_analytic.rb (206 lines)
* assignment_team_analytic.rb (126 lines)
* course_analytic.rb (142 lines)
* question_analytic.rb (12 lines)
* questionnaire_analytic.rb (55 lines)
* response_analytic.rb (101 lines)
* score_analytic.rb (12 lines)

===What they do:===
Display information about various system components in summary form, to aid in analysis.

===What was done:===
Analytic_controller.rb and course_analytic.rb had much duplicated code, which was be factored out. Additionally, analytic_controller.rb had methods that were too complicated, and were be separated into shorter, well-named methods, to make the operation of the class more transparent. Rest of the modules had duplicate code, which was refactored out.

= Analysis =
We used [https://codeclimate.com/github/expertiza/expertiza/code?q=analytic CodeClimate] to analyse the existing code. As can been be seen, there are several classes with duplicate code, high complexity and code smells. 

[[File:code_clime_old.png]]

*High complexity - AnalyticController, CourseAnalytic, QuestionnaireAnalytic
*Duplication – AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
*Smells - AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
 As regards complexity, along with a high overall complexity, the classes also have a high complexity per method ratio

=Code changes=

==Refactoring in AnalyticController==
:1 Usage of inbuilt methods
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = Array.new
courses.each do |course|
course_list << [course.name, course.id]
end
respond_to do |format|
format.json { render :json => sort_by_name(course_list) }
end
end
</pre>

<pre>
def course_list
courses = associated_courses(session[:user])
course_list = courses.map { |course| [course.name, course.id] }
render :json => sort_by_name(course_list)
end
</pre>

The above refactoring was applied to team_list and assignment_list as well.

:2 Use of hashes

<pre>
case params[:type]
when "line"
chart_data = line_graph_data(params[:scope], params[:id], params[:data_type])
when "bar"
chart_data = bar_chart_data(params[:scope], params[:id], params[:data_type])
when "scatter"
chart_data = scatter_plot_data(params[:scope], params[:id], params[:data_type])
when "pie"
chart_data = pie_chart_data(params[:scope], params[:id], params[:data_type])
end

</pre>

Hash was used to adhere to the DRY principle.
<pre>
graph_method_name = {'line' => 'line_graph_data',
'bar' => 'bar_chart_data',
'scatter' => 'scatter_plot_data',
'pie' => 'pie_graph_data'}
graph_data = send(graph_method_name[graph_type], scope, id, data_type)
</pre>

== Refactoring in Modules ==

At many places the developers had added the logic to find, map, get unique object, etc. which already exist in Enumerable module. We changed the code to use these in-built methods. Some of the examples of such changes are:
:1. Code before refactor [self.questionnaire_unique? in assignment_analytic.rb]
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
assignment.questionnaire_types.each do |questionnaire_type|
questionnaire_list = Array.new
assignment.questionnaires.each do |questionnaire|
if questionnaire.type == questionnaire_type
questionnaire_list << questionnaire
end
if questionnaire_list.count > 1
return false
end
end
end
end
return true
end
</pre>

Code after refactoring. Here the inbuilt uniq method was used. If there are duplicates, then unique array length will be less than actual length.
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
questionnaires = assignment.questionnaires
return false if questionnaires.uniq { |q| q.type }.length < questionnaires.length
end
return true
end
</pre>

:2. Code before refactoring [ questionnaire_of_type(type_name_in_string) in assignment_analytic.rb ]
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.each do |questionnaire|
if questionnaire.type == type_name_in_string
return questionnaire
end
end
end
</pre>

Code after refactoring. The find method was used here.
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.find { |questionnaire| questionnaire == type_name_in_string }
end
</pre>

:3 Code before refactoring [average_num_team_reviews in assignment_analytic ]. This pattern existed in many classes.
<pre>
def average_num_team_reviews
if num_teams == 0
0
else
total_num_team_reviews.to_f/num_teams
end
end
</pre>
Code after refactoring.
<pre>
def average_num_team_reviews
total_num_team_reviews.to_f/num_teams
rescue ZeroDivisionError
0
end
</pre>

The code consisted of several functions with unnecessary complexity. We refactored the code to reduce the complexity.
The code consisted of several functions that had duplicate code. These methods transformed a list of objects into a list of one of the object’s attributes. This pattern was removed by creating a generic function.
Following was one of the pattern that existed:

<pre>
# Expertiza code before refactoring in assignment_analytic.rb
def team_review_counts
list = Array.new
self.teams.each do |team|
list << team.num_reviews
end
if (list.empty?)
[0]
else
list
end
end
</pre>

The refactored code for the above logic:

<pre>
# Helper function moved to common_analytic.rb
def extract_from_list(list, property)
list.map { |item| item.send(property) }
end

# Method in assignment_analytic.rb
def team_review_counts
extract_from_list self.teams, :num_reviews
(list.empty?) ? [0] : list
end
</pre>

The logic of the method was exactly what the map method does. Futher, a ternary if-else was used to enhance readability.

The above pattern accounted for majority of the duplicate code.
Code before refactoring [self.types in QuestionnaireAnalytic ]
<pre>
def self.types
type_list = Array.new
self.all.each do |questionnaire|
if !type_list.include?(questionnaire.type)
type_list << questionnaire.type
end
end
type_list
end
</pre>

Code after refactoring.
<pre>
def self.types
type_list = extract_from_list self.all, :type
type_list.uniq
end
</pre>

The following is a list of methods and classes changed for refactoring:
#assignment_analytic.rb
##self.questionnaire_unique?
##questionnaire_of_type
##team_review_counts
##team_scores
#course_analytic.rb
##average_num_assignment_teams
##average_assignment_score
##assignment_review_counts
##assignment_team_counts
##assignment_average_scores
##assignment_max_scores
##assignment_min_scores
#assignment_team_analytic.rb
##average_review_word_count
##average_review_score
##average_review_character_count
##review_character_counts
##review_scores
##review_word_counts
#questionnaire_analytic.rb
##questions_text_list
##word_count_list
##character_count_list
#response_analytic.rb
##word_count_list
##character_count_list
##question_score_list
##comments_text_list

= Post-refactoring report=
[[File:code_clime_new.png]]

Here is a summary of the results.

[[File:Report.png]]

=Future work=
#Currently only bar charts can be seen. Further work can be done to get different kinds of graphs such as pie chart, scatter plot, etc.
#There are some requests that take a long time to respond. For example, View Scores Request. They can be optimized to reduce the response time.

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T18:24:52Z

Mknayak: /* Code changes */

=E818 Refactoring and testing -- analytics=
This Wiki page provides a detailed description of the Open Source Software project conducted on Expertiza, as part of the Object Oriented Languages and Systems coursework.

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is an open source project built using the Ruby on Rails platform. It is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities to manage peer reviews in coursework. The source code can be forked from [https://github.com/expertiza/expertiza github] and cloned for performing modifications. The Expertiza environment is already set up in NC State's VCL image "Ruby on Rails". If you have access, this is quickest way to get a development environment running for Expertiza. See the Expertiza wiki(provide hyperlink) on developing Expertiza on the VCL.

= Overview of project =
===Classes:===
* analytic_controller.rb (163 lines)
* assignment_analytic.rb (206 lines)
* assignment_team_analytic.rb (126 lines)
* course_analytic.rb (142 lines)
* question_analytic.rb (12 lines)
* questionnaire_analytic.rb (55 lines)
* response_analytic.rb (101 lines)
* score_analytic.rb (12 lines)

===What they do:===
Display information about various system components in summary form, to aid in analysis.

===What was done:===
Analytic_controller.rb and course_analytic.rb had much duplicated code, which was be factored out. Additionally, analytic_controller.rb had methods that were too complicated, and were be separated into shorter, well-named methods, to make the operation of the class more transparent. Rest of the modules had duplicate code, which was refactored out.

= Analysis =
We used [https://codeclimate.com/github/expertiza/expertiza/code?q=analytic CodeClimate] to analyse the existing code. As can been be seen, there are several classes with duplicate code, high complexity and code smells. 

[[File:code_clime_old.png]]

*High complexity - AnalyticController, CourseAnalytic, QuestionnaireAnalytic
*Duplication – AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
*Smells - AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
 As regards complexity, along with a high overall complexity, the classes also have a high complexity per method ratio

=Code changes=

Refactoring in AnalyticController
:1 Usage of inbuilt methods
<pre>
def course_list
courses = associated_courses(session[:user])
course_list = Array.new
courses.each do |course|
course_list << [course.name, course.id]
end
respond_to do |format|
format.json { render :json => sort_by_name(course_list) }
end
end
</pre>

<pre>
def course_list
courses = associated_courses(session[:user])
course_list = courses.map { |course| [course.name, course.id] }
render :json => sort_by_name(course_list)
end
</pre>

The above refactoring was applied to team_list and assignment_list as well.

:2 Use of hashes

<pre>
case params[:type]
when "line"
chart_data = line_graph_data(params[:scope], params[:id], params[:data_type])
when "bar"
chart_data = bar_chart_data(params[:scope], params[:id], params[:data_type])
when "scatter"
chart_data = scatter_plot_data(params[:scope], params[:id], params[:data_type])
when "pie"
chart_data = pie_chart_data(params[:scope], params[:id], params[:data_type])
end

</pre>

Hash was used to adhere to the DRY principle.
<pre>
graph_method_name = {'line' => 'line_graph_data',
'bar' => 'bar_chart_data',
'scatter' => 'scatter_plot_data',
'pie' => 'pie_graph_data'}
graph_data = send(graph_method_name[graph_type], scope, id, data_type)
</pre>

At many places the developers had added the logic to find, map, get unique object, etc. which already exist in Enumerable module. We changed the code to use these in-built methods. Some of the examples of such changes are:
:1. Code before refactor [self.questionnaire_unique? in assignment_analytic.rb]
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
assignment.questionnaire_types.each do |questionnaire_type|
questionnaire_list = Array.new
assignment.questionnaires.each do |questionnaire|
if questionnaire.type == questionnaire_type
questionnaire_list << questionnaire
end
if questionnaire_list.count > 1
return false
end
end
end
end
return true
end
</pre>

Code after refactoring. Here the inbuilt uniq method was used. If there are duplicates, then unique array length will be less than actual length.
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
questionnaires = assignment.questionnaires
return false if questionnaires.uniq { |q| q.type }.length < questionnaires.length
end
return true
end
</pre>

:2. Code before refactoring [ questionnaire_of_type(type_name_in_string) in assignment_analytic.rb ]
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.each do |questionnaire|
if questionnaire.type == type_name_in_string
return questionnaire
end
end
end
</pre>

Code after refactoring. The find method was used here.
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.find { |questionnaire| questionnaire == type_name_in_string }
end
</pre>

:3 Code before refactoring [average_num_team_reviews in assignment_analytic ]. This pattern existed in many classes.
<pre>
def average_num_team_reviews
if num_teams == 0
0
else
total_num_team_reviews.to_f/num_teams
end
end
</pre>
Code after refactoring.
<pre>
def average_num_team_reviews
total_num_team_reviews.to_f/num_teams
rescue ZeroDivisionError
0
end
</pre>

The code consisted of several functions with unnecessary complexity. We refactored the code to reduce the complexity.
The code consisted of several functions that had duplicate code. These methods transformed a list of objects into a list of one of the object’s attributes. This pattern was removed by creating a generic function.
Following was one of the pattern that existed:

<pre>
# Expertiza code before refactoring in assignment_analytic.rb
def team_review_counts
list = Array.new
self.teams.each do |team|
list << team.num_reviews
end
if (list.empty?)
[0]
else
list
end
end
</pre>

The refactored code for the above logic:

<pre>
# Helper function moved to common_analytic.rb
def extract_from_list(list, property)
list.map { |item| item.send(property) }
end

# Method in assignment_analytic.rb
def team_review_counts
extract_from_list self.teams, :num_reviews
(list.empty?) ? [0] : list
end
</pre>

The logic of the method was exactly what the map method does. Futher, a ternary if-else was used to enhance readability.

The above pattern accounted for majority of the duplicate code.
Code before refactoring [self.types in QuestionnaireAnalytic ]
<pre>
def self.types
type_list = Array.new
self.all.each do |questionnaire|
if !type_list.include?(questionnaire.type)
type_list << questionnaire.type
end
end
type_list
end
</pre>

Code after refactoring.
<pre>
def self.types
type_list = extract_from_list self.all, :type
type_list.uniq
end
</pre>

The following is a list of methods and classes changed for refactoring:
#assignment_analytic.rb
##self.questionnaire_unique?
##questionnaire_of_type
##team_review_counts
##team_scores
#course_analytic.rb
##average_num_assignment_teams
##average_assignment_score
##assignment_review_counts
##assignment_team_counts
##assignment_average_scores
##assignment_max_scores
##assignment_min_scores
#assignment_team_analytic.rb
##average_review_word_count
##average_review_score
##average_review_character_count
##review_character_counts
##review_scores
##review_word_counts
#questionnaire_analytic.rb
##questions_text_list
##word_count_list
##character_count_list
#response_analytic.rb
##word_count_list
##character_count_list
##question_score_list
##comments_text_list

= Post-refactoring report=
[[File:code_clime_new.png]]

Here is a summary of the results.

[[File:Report.png]]

=Future work=
#Currently only bar charts can be seen. Further work can be done to get different kinds of graphs such as pie chart, scatter plot, etc.
#There are some requests that take a long time to respond. For example, View Scores Request. They can be optimized to reduce the response time.

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T18:11:24Z

Mknayak: /* Code changes */

=E818 Refactoring and testing -- analytics=
This Wiki page provides a detailed description of the Open Source Software project conducted on Expertiza, as part of the Object Oriented Languages and Systems coursework.

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is an open source project built using the Ruby on Rails platform. It is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities to manage peer reviews in coursework. The source code can be forked from [https://github.com/expertiza/expertiza github] and cloned for performing modifications. The Expertiza environment is already set up in NC State's VCL image "Ruby on Rails". If you have access, this is quickest way to get a development environment running for Expertiza. See the Expertiza wiki(provide hyperlink) on developing Expertiza on the VCL.

= Overview of project =
===Classes:===
* analytic_controller.rb (163 lines)
* assignment_analytic.rb (206 lines)
* assignment_team_analytic.rb (126 lines)
* course_analytic.rb (142 lines)
* question_analytic.rb (12 lines)
* questionnaire_analytic.rb (55 lines)
* response_analytic.rb (101 lines)
* score_analytic.rb (12 lines)

===What they do:===
Display information about various system components in summary form, to aid in analysis.

===What was done:===
Analytic_controller.rb and course_analytic.rb had much duplicated code, which was be factored out. Additionally, analytic_controller.rb had methods that were too complicated, and were be separated into shorter, well-named methods, to make the operation of the class more transparent. Rest of the modules had duplicate code, which was refactored out.

= Analysis =
We used [https://codeclimate.com/github/expertiza/expertiza/code?q=analytic CodeClimate] to analyse the existing code. As can been be seen, there are several classes with duplicate code, high complexity and code smells. 

[[File:code_clime_old.png]]

*High complexity - AnalyticController, CourseAnalytic, QuestionnaireAnalytic
*Duplication – AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
*Smells - AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
 As regards complexity, along with a high overall complexity, the classes also have a high complexity per method ratio

=Code changes=

At many places the developers had added the logic to find, map, get unique object, etc. which already exist in Enumerable module. We changed the code to use these in-built methods. Some of the examples of such changes are:
:1. Code before refactor [self.questionnaire_unique? in assignment_analytic.rb]
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
assignment.questionnaire_types.each do |questionnaire_type|
questionnaire_list = Array.new
assignment.questionnaires.each do |questionnaire|
if questionnaire.type == questionnaire_type
questionnaire_list << questionnaire
end
if questionnaire_list.count > 1
return false
end
end
end
end
return true
end
</pre>

Code after refactoring. Here the inbuilt uniq method was used. If there are duplicates, then unique array length will be less than actual length.
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
questionnaires = assignment.questionnaires
return false if questionnaires.uniq { |q| q.type }.length < questionnaires.length
end
return true
end
</pre>

:2. Code before refactoring [ questionnaire_of_type(type_name_in_string) in assignment_analytic.rb ]
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.each do |questionnaire|
if questionnaire.type == type_name_in_string
return questionnaire
end
end
end
</pre>

Code after refactoring. The find method was used here.
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.find { |questionnaire| questionnaire == type_name_in_string }
end
</pre>

:3 Code before refactoring [average_num_team_reviews in assignment_analytic ]. This pattern existed in many classes.
<pre>
def average_num_team_reviews
if num_teams == 0
0
else
total_num_team_reviews.to_f/num_teams
end
end
</pre>
Code after refactoring.
<pre>
def average_num_team_reviews
total_num_team_reviews.to_f/num_teams
rescue ZeroDivisionError
0
end
</pre>

The code consisted of several functions with unnecessary complexity. We refactored the code to reduce the complexity.
The code consisted of several functions that had duplicate code. These methods transformed a list of objects into a list of one of the object’s attributes. This pattern was removed by creating a generic function.
Following was one of the pattern that existed:

<pre>
# Expertiza code before refactoring in assignment_analytic.rb
def team_review_counts
list = Array.new
self.teams.each do |team|
list << team.num_reviews
end
if (list.empty?)
[0]
else
list
end
end
</pre>

The refactored code for the above logic:

<pre>
# Helper function moved to common_analytic.rb
def extract_from_list(list, property)
list.map { |item| item.send(property) }
end

# Method in assignment_analytic.rb
def team_review_counts
extract_from_list self.teams, :num_reviews
(list.empty?) ? [0] : list
end
</pre>

The logic of the method was exactly what the map method does. Futher, a ternary if-else was used to enhance readability.

The above pattern accounted for majority of the duplicate code.
Code before refactoring [self.types in QuestionnaireAnalytic ]
<pre>
def self.types
type_list = Array.new
self.all.each do |questionnaire|
if !type_list.include?(questionnaire.type)
type_list << questionnaire.type
end
end
type_list
end
</pre>

Code after refactoring.
<pre>
def self.types
type_list = extract_from_list self.all, :type
type_list.uniq
end
</pre>

The following is a list of methods and classes changed for refactoring:
#assignment_analytic.rb
##self.questionnaire_unique?
##questionnaire_of_type
##team_review_counts
##team_scores
#course_analytic.rb
##average_num_assignment_teams
##average_assignment_score
##assignment_review_counts
##assignment_team_counts
##assignment_average_scores
##assignment_max_scores
##assignment_min_scores
#assignment_team_analytic.rb
##average_review_word_count
##average_review_score
##average_review_character_count
##review_character_counts
##review_scores
##review_word_counts
#questionnaire_analytic.rb
##questions_text_list
##word_count_list
##character_count_list
#response_analytic.rb
##word_count_list
##character_count_list
##question_score_list
##comments_text_list

= Post-refactoring report=
[[File:code_clime_new.png]]

Here is a summary of the results.

[[File:Report.png]]

=Future work=
#Currently only bar charts can be seen. Further work can be done to get different kinds of graphs such as pie chart, scatter plot, etc.
#There are some requests that take a long time to respond. For example, View Scores Request. They can be optimized to reduce the response time.

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T17:53:41Z

Mknayak: /* What was done: */

=E818 Refactoring and testing -- analytics=
This Wiki page provides a detailed description of the Open Source Software project conducted on Expertiza, as part of the Object Oriented Languages and Systems coursework.

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is an open source project built using the Ruby on Rails platform. It is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities to manage peer reviews in coursework. The source code can be forked from [https://github.com/expertiza/expertiza github] and cloned for performing modifications. The Expertiza environment is already set up in NC State's VCL image "Ruby on Rails". If you have access, this is quickest way to get a development environment running for Expertiza. See the Expertiza wiki(provide hyperlink) on developing Expertiza on the VCL.

= Overview of project =
===Classes:===
* analytic_controller.rb (163 lines)
* assignment_analytic.rb (206 lines)
* assignment_team_analytic.rb (126 lines)
* course_analytic.rb (142 lines)
* question_analytic.rb (12 lines)
* questionnaire_analytic.rb (55 lines)
* response_analytic.rb (101 lines)
* score_analytic.rb (12 lines)

===What they do:===
Display information about various system components in summary form, to aid in analysis.

===What was done:===
Analytic_controller.rb and course_analytic.rb had much duplicated code, which was be factored out. Additionally, analytic_controller.rb had methods that were too complicated, and were be separated into shorter, well-named methods, to make the operation of the class more transparent. Rest of the modules had duplicate code, which was refactored out.

= Analysis =
We used [https://codeclimate.com/github/expertiza/expertiza/code?q=analytic CodeClimate] to analyse the existing code. As can been be seen, there are several classes with duplicate code, high complexity and code smells. 

[[File:code_clime_old.png]]

*High complexity - AnalyticController, CourseAnalytic, QuestionnaireAnalytic
*Duplication – AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
*Smells - AnalyticController, AssignmentAnalytic, AssignmentTeamAnalytic, CourseAnalytic, ResponseAnalytic
 As regards complexity, along with a high overall complexity, the classes also have a high complexity per method ratio

=Code changes=

At many places the developers had added the logic to find, map, get unique object, etc. which already exist in Enumerable module. We changed the code to use these in-built methods. Some of the examples of such changes are:
:1. Code before refactor [self.questionnaire_unique? in assignment_analytic.rb]
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
assignment.questionnaire_types.each do |questionnaire_type|
questionnaire_list = Array.new
assignment.questionnaires.each do |questionnaire|
if questionnaire.type == questionnaire_type
questionnaire_list << questionnaire
end
if questionnaire_list.count > 1
return false
end
end
end
end
return true
end
</pre>

Code after refactoring. Here the inbuilt uniq method was used. If there are duplicates, then unique array length will be less than actual length.
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
questionnaires = assignment.questionnaires
return false if questionnaires.uniq { |q| q.type }.length < questionnaires.length
end
return true
end
</pre>

:2. Code before refactoring [ questionnaire_of_type(type_name_in_string) in assignment_analytic.rb ]
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.each do |questionnaire|
if questionnaire.type == type_name_in_string
return questionnaire
end
end
end
</pre>

Code after refactoring. The find method was used here.
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.find { |questionnaire| questionnaire == type_name_in_string }
end
</pre>

:3 Code before refactoring [average_num_team_reviews in assignment_analytic ]. This pattern existed in many classes.
<pre>
def average_num_team_reviews
if num_teams == 0
0
else
total_num_team_reviews.to_f/num_teams
end
end
</pre>
Code after refactoring.
<pre>
def average_num_team_reviews
total_num_team_reviews.to_f/num_teams
rescue ZeroDivisionError
0
end
</pre>

#The code consisted of several functions with unnecessary complexity. We refactored the code to reduce the complexity.
#The code consisted of several functions that had duplicate code. These methods transformed a list of objects into a list of one of the object’s attributes. This pattern was removed by creating a generic function.
Following was one of the pattern that existed:

<pre>
# Expertiza code before refactoring in assignment_analytic.rb
def team_review_counts
list = Array.new
self.teams.each do |team|
list << team.num_reviews
end
if (list.empty?)
[0]
else
list
end
end
</pre>

The refactored code for the above logic:

<pre>
# Helper function moved to common_analytic.rb
def extract_from_list(list, property)
list.map { |item| item.send(property) }
end

# Method in assignment_analytic.rb
def team_review_counts
extract_from_list self.teams, :num_reviews
(list.empty?) ? [0] : list
end
</pre>

The above pattern accounted for majority of the duplicate code.
Code before refactoring [self.types in QuestionnaireAnalytic ]
<pre>
def self.types
type_list = Array.new
self.all.each do |questionnaire|
if !type_list.include?(questionnaire.type)
type_list << questionnaire.type
end
end
type_list
end
</pre>

Code after refactoring.
<pre>
def self.types
type_list = extract_from_list self.all, :type
type_list.uniq
end
</pre>

The following is a list of methods and classes changed for refactoring:
#assignment_analytic.rb
##self.questionnaire_unique?
##questionnaire_of_type
##team_review_counts
##team_scores
#course_analytic.rb
##average_num_assignment_teams
##average_assignment_score
##assignment_review_counts
##assignment_team_counts
##assignment_average_scores
##assignment_max_scores
##assignment_min_scores
#assignment_team_analytic.rb
##average_review_word_count
##average_review_score
##average_review_character_count
##review_character_counts
##review_scores
##review_word_counts
#questionnaire_analytic.rb
##questions_text_list
##word_count_list
##character_count_list
#response_analytic.rb
##word_count_list
##character_count_list
##question_score_list
##comments_text_list

= Post-refactoring report=
[[File:code_clime_new.png]]

Here is a summary of the results.

[[File:Report.png]]

=Future work=
#Currently only bar charts can be seen. Further work can be done to get different kinds of graphs such as pie chart, scatter plot, etc.
#There are some requests that take a long time to respond. For example, View Scores Request. They can be optimized to reduce the response time.

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T17:49:58Z

Mknayak: /* Analysis */

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T17:46:40Z

Mknayak:

File:Report.png

2013-10-30T17:46:09Z

Mknayak:

File:Code clime new.png

2013-10-30T17:43:46Z

Mknayak:

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T17:38:19Z

Mknayak: /* Analysis */

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T17:35:24Z

Mknayak: /* Analysis */

File:Code clime old.png

2013-10-30T17:33:05Z

Mknayak: uploaded a new version of "File:Code clime old.png"

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T17:30:34Z

Mknayak:

File:Code clime old.png

2013-10-30T17:29:44Z

Mknayak:

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T17:23:28Z

Mknayak: /* Code changes */

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T16:46:47Z

Mknayak: /* Code changes */

=Topic and short description (E818 Refactoring and testing -- analytics)=
===Classes:===
* analytic_controller.rb (163 lines)
* assignment_analytic.rb (206 lines)
* assignment_team_analytic.rb (126 lines)
* course_analytic.rb (142 lines)
* question_analytic.rb (12 lines)
* questionnaire_analytic.rb (55 lines)
* response_analytic.rb (101 lines)
* score_analytic.rb (12 lines)

===What they do:===
Display information about various system components in summary form, to aid in analysis.

===What needs to be done:===
At least analytic_controller.rb and course_analytic.rb have much duplicated code, which should be factored out. Additionally, analytic_controller.rb has methods that are too complicated, and should be separated into shorter, well-named methods, to make the operation of the class more transparent. Also, there are absolutely no tests for any of these methods.

=Code changes=

At many places the developers had added the logic to find, map, get unique object, etc. which already exist in Enumerable module. We changed the code to use these in-built methods. Some of the examples of such changes are:
#Code before refactor [self.questionnaire_unique? in assignment_analytic.rb]
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
assignment.questionnaire_types.each do |questionnaire_type|
questionnaire_list = Array.new
assignment.questionnaires.each do |questionnaire|
if questionnaire.type == questionnaire_type
questionnaire_list << questionnaire
end
if questionnaire_list.count > 1
return false
end
end
end
end
return true
end
</pre>

Code after refactoring. Here the inbuilt uniq method was used. If there are duplicates, then unique array length will be less than actual length.
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
questionnaires = assignment.questionnaires
return false if questionnaires.uniq { |q| q.type }.length < questionnaires.length
end
return true
end
</pre>

#Code before refactoring [ questionnaire_of_type(type_name_in_string) in assignment_analytic.rb ]
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.each do |questionnaire|
if questionnaire.type == type_name_in_string
return questionnaire
end
end
end
</pre>

Code after refactoring. The find method was used here.
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.find { |questionnaire| questionnaire == type_name_in_string }
end
</pre>

#Code before refactoring [average_num_team_reviews in assignment_analytic ]
<pre>
def average_num_team_reviews
if num_teams == 0
0
else
total_num_team_reviews.to_f/num_teams
end
end
</pre>
Code after refactoring.
<pre>
def average_num_team_reviews
total_num_team_reviews.to_f/num_teams
rescue ZeroDivisionError
0
end
</pre>
#The code consisted of several functions with unnecessary complexity. We refactored the code to reduce the complexity.
#The code consisted of several functions that had duplicate code. These methods transformed a list of objects into a list of one of the object’s attributes. This pattern was removed by creating a generic function.
Following was one of the pattern that existed:

<pre>
# Expertiza code before refactoring in assignment_analytic.rb
def team_review_counts
list = Array.new
self.teams.each do |team|
list << team.num_reviews
end
if (list.empty?)
[0]
else
list
end
end
</pre>

The refactored code for the above logic:

<pre>
# Helper function moved to common_analytic.rb
def extract_from_list(list, property)
list.map { |item| item.send(property) }
end

# Method in assignment_analytic.rb
def team_review_counts
extract_from_list self.teams, :num_reviews
(list.empty?) ? [0] : list
end
</pre>

The following is a list of methods and classes changed for refactoring:
#assignment_analytic.rb
##self.questionnaire_unique?
##questionnaire_of_type
##team_review_counts
##team_scores
#course_analytic.rb
##average_num_assignment_teams
##average_assignment_score
##assignment_review_counts
##assignment_team_counts
##assignment_average_scores
##assignment_max_scores
##assignment_min_scores
#assignment_team_analytic.rb
##average_review_word_count
##average_review_score
##average_review_character_count
##review_character_counts
##review_scores
##review_word_counts
#questionnaire_analytic.rb
##questions_text_list
##word_count_list
##character_count_list
#response_analytic.rb
##word_count_list
##character_count_list
##question_score_list
##comments_text_list

=Future work=
#Currently only bar charts can be seen. Further work can be done to get different kinds of graphs such as pie chart, scatter plot, etc.
#There are some requests that take a long time to respond. For example, View Scores Request. They can be optimized to reduce the response time.

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T16:46:07Z

Mknayak: /* Code changes */

=Topic and short description (E818 Refactoring and testing -- analytics)=
===Classes:===
* analytic_controller.rb (163 lines)
* assignment_analytic.rb (206 lines)
* assignment_team_analytic.rb (126 lines)
* course_analytic.rb (142 lines)
* question_analytic.rb (12 lines)
* questionnaire_analytic.rb (55 lines)
* response_analytic.rb (101 lines)
* score_analytic.rb (12 lines)

===What they do:===
Display information about various system components in summary form, to aid in analysis.

===What needs to be done:===
At least analytic_controller.rb and course_analytic.rb have much duplicated code, which should be factored out. Additionally, analytic_controller.rb has methods that are too complicated, and should be separated into shorter, well-named methods, to make the operation of the class more transparent. Also, there are absolutely no tests for any of these methods.

=Code changes=

# At many places the developers had added the logic to find, map, get unique object, etc. which already exist in Enumerable module. We changed the code to use these in-built methods. Some of the examples of such changes are:
##Code before refactor [self.questionnaire_unique? in assignment_analytic.rb]
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
assignment.questionnaire_types.each do |questionnaire_type|
questionnaire_list = Array.new
assignment.questionnaires.each do |questionnaire|
if questionnaire.type == questionnaire_type
questionnaire_list << questionnaire
end
if questionnaire_list.count > 1
return false
end
end
end
end
return true
end
</pre>

Code after refactoring. Here the inbuilt uniq method was used. If there are duplicates, then unique array length will be less than actual length.
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
questionnaires = assignment.questionnaires
return false if questionnaires.uniq { |q| q.type }.length < questionnaires.length
end
return true
end
</pre>

##Code before refactoring [ questionnaire_of_type(type_name_in_string) in assignment_analytic.rb ]
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.each do |questionnaire|
if questionnaire.type == type_name_in_string
return questionnaire
end
end
end
</pre>

Code after refactoring. The find method was used here.
<pre>
def questionnaire_of_type(type_name_in_string)
self.questionnaires.find { |questionnaire| questionnaire == type_name_in_string }
end
</pre>
Code before refactoring [average_num_team_reviews in assignment_analytic ]
<pre>
def average_num_team_reviews
if num_teams == 0
0
else
total_num_team_reviews.to_f/num_teams
end
end
</pre>
Code after refactoring.
<pre>
def average_num_team_reviews
total_num_team_reviews.to_f/num_teams
rescue ZeroDivisionError
0
end
</pre>
#The code consisted of several functions with unnecessary complexity. We refactored the code to reduce the complexity.
#The code consisted of several functions that had duplicate code. These methods transformed a list of objects into a list of one of the object’s attributes. This pattern was removed by creating a generic function.
Following was one of the pattern that existed:

<pre>
# Expertiza code before refactoring in assignment_analytic.rb
def team_review_counts
list = Array.new
self.teams.each do |team|
list << team.num_reviews
end
if (list.empty?)
[0]
else
list
end
end
</pre>

The refactored code for the above logic:

<pre>
# Helper function moved to common_analytic.rb
def extract_from_list(list, property)
list.map { |item| item.send(property) }
end

# Method in assignment_analytic.rb
def team_review_counts
extract_from_list self.teams, :num_reviews
(list.empty?) ? [0] : list
end
</pre>

The following is a list of methods and classes changed for refactoring:
#assignment_analytic.rb
##self.questionnaire_unique?
##questionnaire_of_type
##team_review_counts
##team_scores
#course_analytic.rb
##average_num_assignment_teams
##average_assignment_score
##assignment_review_counts
##assignment_team_counts
##assignment_average_scores
##assignment_max_scores
##assignment_min_scores
#assignment_team_analytic.rb
##average_review_word_count
##average_review_score
##average_review_character_count
##review_character_counts
##review_scores
##review_word_counts
#questionnaire_analytic.rb
##questions_text_list
##word_count_list
##character_count_list
#response_analytic.rb
##word_count_list
##character_count_list
##question_score_list
##comments_text_list

=Future work=
#Currently only bar charts can be seen. Further work can be done to get different kinds of graphs such as pie chart, scatter plot, etc.
#There are some requests that take a long time to respond. For example, View Scores Request. They can be optimized to reduce the response time.

CSC/ECE 517 Fall 2013/oss E818 mra

2013-10-30T16:39:09Z

Mknayak: /* Code changes */

=Topic and short description (E818 Refactoring and testing -- analytics)=
===Classes:===
* analytic_controller.rb (163 lines)
* assignment_analytic.rb (206 lines)
* assignment_team_analytic.rb (126 lines)
* course_analytic.rb (142 lines)
* question_analytic.rb (12 lines)
* questionnaire_analytic.rb (55 lines)
* response_analytic.rb (101 lines)
* score_analytic.rb (12 lines)

===What they do:===
Display information about various system components in summary form, to aid in analysis.

===What needs to be done:===
At least analytic_controller.rb and course_analytic.rb have much duplicated code, which should be factored out. Additionally, analytic_controller.rb has methods that are too complicated, and should be separated into shorter, well-named methods, to make the operation of the class more transparent. Also, there are absolutely no tests for any of these methods.

=Code changes=

# At many places the developers had added the logic to find, map, get unique object, etc. which already exist in Enumerable module. We changed the code to use these in-built methods. Some of the examples of such changes are:
Code before refactor
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
assignment.questionnaire_types.each do |questionnaire_type|
questionnaire_list = Array.new
assignment.questionnaires.each do |questionnaire|
if questionnaire.type == questionnaire_type
questionnaire_list << questionnaire
end
if questionnaire_list.count > 1
return false
end
end
end
end
return true
end
</pre>

Code after refactoring. Here the inbuilt uniq method was used. If there are duplicates, then unique array length will be less than actual length.
<pre>
def self.questionnaire_unique?
self.all.each do |assignment|
questionnaires = assignment.questionnaires
return false if questionnaires.uniq { |q| q.type }.length < questionnaires.length
end
return true
end
</pre>
##self.questionnaire_unique? in assignment_analytic.rb
##questionnaire_of_type(type_name_in_string) in assignment_analytic.rb
#The code consisted of several functions with unnecessary complexity. We refactored the code to reduce the complexity.
#The code consisted of several functions that had duplicate code. These methods transformed a list of objects into a list of one of the object’s attributes. This pattern was removed by creating a generic function.
Following was one of the pattern that existed:

<pre>
# Expertiza code before refactoring in assignment_analytic.rb
def team_review_counts
list = Array.new
self.teams.each do |team|
list << team.num_reviews
end
if (list.empty?)
[0]
else
list
end
end
</pre>

The refactored code for the above logic:

<pre>
# Helper function moved to common_analytic.rb
def extract_from_list(list, property)
list.map { |item| item.send(property) }
end

# Method in assignment_analytic.rb
def team_review_counts
extract_from_list self.teams, :num_reviews
(list.empty?) ? [0] : list
end
</pre>

The following is a list of methods and classes changed for refactoring:
#assignment_analytic.rb
##self.questionnaire_unique?
##questionnaire_of_type
##team_review_counts
##team_scores
#course_analytic.rb
##average_num_assignment_teams
##average_assignment_score
##assignment_review_counts
##assignment_team_counts
##assignment_average_scores
##assignment_max_scores
##assignment_min_scores
#assignment_team_analytic.rb
##average_review_word_count
##average_review_score
##average_review_character_count
##review_character_counts
##review_scores
##review_word_counts
#questionnaire_analytic.rb
##questions_text_list
##word_count_list
##character_count_list
#response_analytic.rb
##word_count_list
##character_count_list
##question_score_list
##comments_text_list

=Future work=
#Currently only bar charts can be seen. Further work can be done to get different kinds of graphs such as pie chart, scatter plot, etc.
#There are some requests that take a long time to respond. For example, View Scores Request. They can be optimized to reduce the response time.

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-25T00:39:47Z

Mknayak: /* app/ */

== MVC Architecture Structure In Ruby on Rails ==

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces [http://en.wikipedia.org/wiki/Agile_software_development agile web development]. Rails framework leverages the features of the Ruby language. Ruby is a [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed], object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|frame|center| MVC Flow Diagram. Image Credit: Wikipedia]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, [http://en.wikipedia.org/wiki/JSON JSON]. The view does not do any processing, but simply acts as the [http://en.wikipedia.org/wiki/Presentation_layer presentation layer] , displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers are only concerned with the model structure and need not know the underlying architecture,
 

== How Rails MVC Works ==
[[File:wiki.PNG|center|frame| MVC Architecture working and control flow]]

MVC Architecture working can be explained as follows:
The model, view and controller are referred to as Active Record, Action View and Action Controller respectively here.

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it is the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates. The application data is used to fill these templates. The resultant HTML response is sent to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices. This is referred to as [http://en.wikipedia.org/wiki/Convention_over_configuration Convention over configuration]

There are some types of applications in which Ruby on Rails Architecture is not suitable:

#Sites that depend on large amount of existing code or legacy code or legacy databases. 
#Requirements where dozens or hundreds of websites are residing in a single server. 
#Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

:[1] [http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
:[2] [http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
:[3] [http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
:[4] [http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
:[5] [http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
:[6] [http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
:[7] [http://guides.rubyonrails.org/testing.html Testing in Rails] 
:[8] [http://guides.rubyonrails.org/migrations.html Database Migrations] 
<references />

== Further Reading ==

*[http://ruby-on-rails.wonderhowto.com/how-to/work-with-mvc-architecture-when-writing-ruby-rails-application-405802/ How to work with MVC in Ruby on Rails]
*[http://www.devarticles.com/c/a/Ruby-on-Rails/The-MVC-Pattern-in-the-Rails-Framework/ The MVC pattern in Rails framework]
*[http://ruby.railstutorial.org/chapters/a-demo-app Learn MVC development in Rails]
*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-25T00:38:31Z

Mknayak: /* Further Reading */

== MVC Architecture Structure In Ruby on Rails ==

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces [http://en.wikipedia.org/wiki/Agile_software_development agile web development]. Rails framework leverages the features of the Ruby language. Ruby is a [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed], object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|frame|center| MVC Flow Diagram. Image Credit: Wikipedia]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, [http://en.wikipedia.org/wiki/JSON JSON]. The view does not do any processing, but simply acts as the [http://en.wikipedia.org/wiki/Presentation_layer presentation layer] , displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers are only concerned with the model structure and need not know the underlying architecture,
 

== How Rails MVC Works ==
[[File:wiki.PNG|center|frame| MVC Architecture working and control flow]]

MVC Architecture working can be explained as follows:
The model, view and controller are referred to as Active Record, Action View and Action Controller respectively here.

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it is the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices. This is referred to as [http://en.wikipedia.org/wiki/Convention_over_configuration Convention over configuration]

There are some types of applications in which Ruby on Rails Architecture is not suitable:

#Sites that depend on large amount of existing code or legacy code or legacy databases. 
#Requirements where dozens or hundreds of websites are residing in a single server. 
#Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

:[1] [http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
:[2] [http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
:[3] [http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
:[4] [http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
:[5] [http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
:[6] [http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
:[7] [http://guides.rubyonrails.org/testing.html Testing in Rails] 
:[8] [http://guides.rubyonrails.org/migrations.html Database Migrations] 
<references />

== Further Reading ==

*[http://ruby-on-rails.wonderhowto.com/how-to/work-with-mvc-architecture-when-writing-ruby-rails-application-405802/ How to work with MVC in Ruby on Rails]
*[http://www.devarticles.com/c/a/Ruby-on-Rails/The-MVC-Pattern-in-the-Rails-Framework/ The MVC pattern in Rails framework]
*[http://ruby.railstutorial.org/chapters/a-demo-app Learn MVC development in Rails]
*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-25T00:34:25Z

Mknayak: /* How Rails MVC Works */

== MVC Architecture Structure In Ruby on Rails ==

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces [http://en.wikipedia.org/wiki/Agile_software_development agile web development]. Rails framework leverages the features of the Ruby language. Ruby is a [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed], object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|frame|center| MVC Flow Diagram. Image Credit: Wikipedia]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, [http://en.wikipedia.org/wiki/JSON JSON]. The view does not do any processing, but simply acts as the [http://en.wikipedia.org/wiki/Presentation_layer presentation layer] , displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers are only concerned with the model structure and need not know the underlying architecture,
 

== How Rails MVC Works ==
[[File:wiki.PNG|center|frame| MVC Architecture working and control flow]]

MVC Architecture working can be explained as follows:
The model, view and controller are referred to as Active Record, Action View and Action Controller respectively here.

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it is the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices. This is referred to as [http://en.wikipedia.org/wiki/Convention_over_configuration Convention over configuration]

There are some types of applications in which Ruby on Rails Architecture is not suitable:

#Sites that depend on large amount of existing code or legacy code or legacy databases. 
#Requirements where dozens or hundreds of websites are residing in a single server. 
#Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

:[1] [http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
:[2] [http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
:[3] [http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
:[4] [http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
:[5] [http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
:[6] [http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
:[7] [http://guides.rubyonrails.org/testing.html Testing in Rails] 
:[8] [http://guides.rubyonrails.org/migrations.html Database Migrations] 
<references />

== Further Reading ==

*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-25T00:32:43Z

Mknayak: /* Controller */

== MVC Architecture Structure In Ruby on Rails ==

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces [http://en.wikipedia.org/wiki/Agile_software_development agile web development]. Rails framework leverages the features of the Ruby language. Ruby is a [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed], object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|frame|center| MVC Flow Diagram. Image Credit: Wikipedia]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, [http://en.wikipedia.org/wiki/JSON JSON]. The view does not do any processing, but simply acts as the [http://en.wikipedia.org/wiki/Presentation_layer presentation layer] , displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers are only concerned with the model structure and need not know the underlying architecture,
 

== How Rails MVC Works ==
[[File:wiki.PNG|center|frame| MVC Architecture working and control flow]]

MVC Architecture working can be explained as follows:
The model, view and controller are referred to as Active Record, Action View and Action Controller respectively here.

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it’s the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices. This is referred to as [http://en.wikipedia.org/wiki/Convention_over_configuration Convention over configuration]

There are some types of applications in which Ruby on Rails Architecture is not suitable:

#Sites that depend on large amount of existing code or legacy code or legacy databases. 
#Requirements where dozens or hundreds of websites are residing in a single server. 
#Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

:[1] [http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
:[2] [http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
:[3] [http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
:[4] [http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
:[5] [http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
:[6] [http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
:[7] [http://guides.rubyonrails.org/testing.html Testing in Rails] 
:[8] [http://guides.rubyonrails.org/migrations.html Database Migrations] 
<references />

== Further Reading ==

*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-25T00:29:15Z

Mknayak: /* app/ */

== MVC Architecture Structure In Ruby on Rails ==

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces [http://en.wikipedia.org/wiki/Agile_software_development agile web development]. Rails framework leverages the features of the Ruby language. Ruby is a [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed], object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|frame|center| MVC Flow Diagram. Image Credit: Wikipedia]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, [http://en.wikipedia.org/wiki/JSON JSON]. The view does not do any processing, but simply acts as the [http://en.wikipedia.org/wiki/Presentation_layer presentation layer] , displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers need not know of the underlying architecture, and are only concerned with the model structure.
 

== How Rails MVC Works ==
[[File:wiki.PNG|center|frame| MVC Architecture working and control flow]]

MVC Architecture working can be explained as follows:
The model, view and controller are referred to as Active Record, Action View and Action Controller respectively here.

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it’s the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices. This is referred to as [http://en.wikipedia.org/wiki/Convention_over_configuration Convention over configuration]

There are some types of applications in which Ruby on Rails Architecture is not suitable:

#Sites that depend on large amount of existing code or legacy code or legacy databases. 
#Requirements where dozens or hundreds of websites are residing in a single server. 
#Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

:[1] [http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
:[2] [http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
:[3] [http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
:[4] [http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
:[5] [http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
:[6] [http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
:[7] [http://guides.rubyonrails.org/testing.html Testing in Rails] 
:[8] [http://guides.rubyonrails.org/migrations.html Database Migrations] 
<references />

== Further Reading ==

*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-25T00:28:01Z

Mknayak: /* View */

== MVC Architecture Structure In Ruby on Rails ==

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces [http://en.wikipedia.org/wiki/Agile_software_development agile web development]. Rails framework leverages the features of the Ruby language. Ruby is a [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed], object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|frame|center| MVC Flow Diagram. Image Credit: Wikipedia]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, [http://en.wikipedia.org/wiki/JSON JSON]. The view does not do any processing, but simply acts as the [http://en.wikipedia.org/wiki/Presentation_layer presentation layer] , displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers need not know of the underlying architecture, and are only concerned with the model structure.
 

== How Rails MVC Works ==
[[File:wiki.PNG|center|frame| MVC Architecture working and control flow]]

MVC Architecture working can be explained as follows:
The model, view and controller are referred to as Active Record, Action View and Action Controller respectively here.

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it’s the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. We need to keep as much Ruby code out of the views as possible, so helpers are mainly for use in that context. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices. This is referred to as [http://en.wikipedia.org/wiki/Convention_over_configuration Convention over configuration]

There are some types of applications in which Ruby on Rails Architecture is not suitable:

#Sites that depend on large amount of existing code or legacy code or legacy databases. 
#Requirements where dozens or hundreds of websites are residing in a single server. 
#Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

:[1] [http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
:[2] [http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
:[3] [http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
:[4] [http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
:[5] [http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
:[6] [http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
:[7] [http://guides.rubyonrails.org/testing.html Testing in Rails] 
:[8] [http://guides.rubyonrails.org/migrations.html Database Migrations] 
<references />

== Further Reading ==

*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-25T00:22:51Z

Mknayak: /* Introduction */

== MVC Architecture Structure In Ruby on Rails ==

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces [http://en.wikipedia.org/wiki/Agile_software_development agile web development]. Rails framework leverages the features of the Ruby language. Ruby is a [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed], object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|frame|center| MVC Flow Diagram. Image Credit: Wikipedia]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, JSON. The view does not do any processing, but simply acts as the presentation layer, displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers need not know of the underlying architecture, and are only concerned with the model structure.
 

== How Rails MVC Works ==
[[File:wiki.PNG|center|frame| MVC Architecture working and control flow]]

MVC Architecture working can be explained as follows:
The model, view and controller are referred to as Active Record, Action View and Action Controller respectively here.

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it’s the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. We need to keep as much Ruby code out of the views as possible, so helpers are mainly for use in that context. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices. This is referred to as [http://en.wikipedia.org/wiki/Convention_over_configuration Convention over configuration]

There are some types of applications in which Ruby on Rails Architecture is not suitable:

#Sites that depend on large amount of existing code or legacy code or legacy databases. 
#Requirements where dozens or hundreds of websites are residing in a single server. 
#Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

:[1] [http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
:[2] [http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
:[3] [http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
:[4] [http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
:[5] [http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
:[6] [http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
:[7] [http://guides.rubyonrails.org/testing.html Testing in Rails] 
:[8] [http://guides.rubyonrails.org/migrations.html Database Migrations] 
<references />

== Further Reading ==

*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-25T00:19:27Z

Mknayak: /* References */

== MVC Architecture Structure In Ruby on Rails ==

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces agile web development. Rails framework leverages the features of the Ruby language. Ruby is a dynamically typed, object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|frame|center| MVC Flow Diagram. Image Credit: Wikipedia]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, JSON. The view does not do any processing, but simply acts as the presentation layer, displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers need not know of the underlying architecture, and are only concerned with the model structure.
 

== How Rails MVC Works ==
[[File:wiki.PNG|center|frame| MVC Architecture working and control flow]]

MVC Architecture working can be explained as follows:
The model, view and controller are referred to as Active Record, Action View and Action Controller respectively here.

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it’s the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. We need to keep as much Ruby code out of the views as possible, so helpers are mainly for use in that context. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices. This is referred to as [http://en.wikipedia.org/wiki/Convention_over_configuration Convention over configuration]

There are some types of applications in which Ruby on Rails Architecture is not suitable:

#Sites that depend on large amount of existing code or legacy code or legacy databases. 
#Requirements where dozens or hundreds of websites are residing in a single server. 
#Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

:[1] [http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
:[2] [http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
:[3] [http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
:[4] [http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
:[5] [http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
:[6] [http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
:[7] [http://guides.rubyonrails.org/testing.html Testing in Rails] 
:[8] [http://guides.rubyonrails.org/migrations.html Database Migrations] 
<references />

== Further Reading ==

*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-25T00:17:58Z

Mknayak: /* MVC Architecture Structure In Ruby on Rails */

== MVC Architecture Structure In Ruby on Rails ==

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces agile web development. Rails framework leverages the features of the Ruby language. Ruby is a dynamically typed, object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|frame|center| MVC Flow Diagram. Image Credit: Wikipedia]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, JSON. The view does not do any processing, but simply acts as the presentation layer, displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers need not know of the underlying architecture, and are only concerned with the model structure.
 

== How Rails MVC Works ==
[[File:wiki.PNG|center|frame| MVC Architecture working and control flow]]

MVC Architecture working can be explained as follows:
The model, view and controller are referred to as Active Record, Action View and Action Controller respectively here.

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it’s the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. We need to keep as much Ruby code out of the views as possible, so helpers are mainly for use in that context. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices. This is referred to as [http://en.wikipedia.org/wiki/Convention_over_configuration Convention over configuration]

There are some types of applications in which Ruby on Rails Architecture is not suitable:

#Sites that depend on large amount of existing code or legacy code or legacy databases. 
#Requirements where dozens or hundreds of websites are residing in a single server. 
#Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

:[1] [http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
:[2] [http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
:[3][http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
:[4] [http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
:[5] [http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
:[6] [http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
:[7] [http://guides.rubyonrails.org/testing.html Testing in Rails] 
:[8] [http://guides.rubyonrails.org/migrations.html Database Migrations] 
<references />

== Further Reading ==

*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-25T00:14:02Z

Mknayak: /* Decision of convention over configuration */

= MVC Architecture Structure In Ruby on Rails =

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces agile web development. Rails framework leverages the features of the Ruby language. Ruby is a dynamically typed, object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|frame|center| MVC Flow Diagram. Image Credit: Wikipedia]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, JSON. The view does not do any processing, but simply acts as the presentation layer, displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers need not know of the underlying architecture, and are only concerned with the model structure.
 

== How Rails MVC Works ==
[[File:wiki.PNG|center|frame| MVC Architecture working and control flow]]

MVC Architecture working can be explained as follows:
The model, view and controller are referred to as Active Record, Action View and Action Controller respectively here.

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it’s the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. We need to keep as much Ruby code out of the views as possible, so helpers are mainly for use in that context. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices. This is referred to as [http://en.wikipedia.org/wiki/Convention_over_configuration Convention over configuration]

There are some types of applications in which Ruby on Rails Architecture is not suitable:

#Sites that depend on large amount of existing code or legacy code or legacy databases. 
#Requirements where dozens or hundreds of websites are residing in a single server. 
#Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

:[1] [http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
:[2] [http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
:[3][http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
:[4] [http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
:[5] [http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
:[6] [http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
:[7] [http://guides.rubyonrails.org/testing.html Testing in Rails] 
:[8] [http://guides.rubyonrails.org/migrations.html Database Migrations] 
<references />

== Further Reading ==

*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-25T00:12:55Z

Mknayak: /* References */

= MVC Architecture Structure In Ruby on Rails =

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces agile web development. Rails framework leverages the features of the Ruby language. Ruby is a dynamically typed, object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|frame|center| MVC Flow Diagram. Image Credit: Wikipedia]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, JSON. The view does not do any processing, but simply acts as the presentation layer, displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers need not know of the underlying architecture, and are only concerned with the model structure.
 

== How Rails MVC Works ==
[[File:wiki.PNG|center|frame| MVC Architecture working and control flow]]

MVC Architecture working can be explained as follows:
The model, view and controller are referred to as Active Record, Action View and Action Controller respectively here.

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it’s the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. We need to keep as much Ruby code out of the views as possible, so helpers are mainly for use in that context. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices.

There are some types of applications in which Ruby on Rails Architecture is not suitable:

#Sites that depend on large amount of existing code or legacy code or legacy databases. 
#Requirements where dozens or hundreds of websites are residing in a single server. 
#Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

:[1] [http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
:[2] [http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
:[3][http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
:[4] [http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
:[5] [http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
:[6] [http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
:[7] [http://guides.rubyonrails.org/testing.html Testing in Rails] 
:[8] [http://guides.rubyonrails.org/migrations.html Database Migrations] 
<references />

== Further Reading ==

*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-25T00:11:15Z

Mknayak: /* What is MVC */

= MVC Architecture Structure In Ruby on Rails =

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces agile web development. Rails framework leverages the features of the Ruby language. Ruby is a dynamically typed, object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|frame|center| MVC Flow Diagram. Image Credit: Wikipedia]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, JSON. The view does not do any processing, but simply acts as the presentation layer, displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers need not know of the underlying architecture, and are only concerned with the model structure.
 

== How Rails MVC Works ==
[[File:wiki.PNG|center|frame| MVC Architecture working and control flow]]

MVC Architecture working can be explained as follows:
The model, view and controller are referred to as Active Record, Action View and Action Controller respectively here.

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it’s the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. We need to keep as much Ruby code out of the views as possible, so helpers are mainly for use in that context. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices.

There are some types of applications in which Ruby on Rails Architecture is not suitable:

#Sites that depend on large amount of existing code or legacy code or legacy databases. 
#Requirements where dozens or hundreds of websites are residing in a single server. 
#Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

*[http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
*[http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
*[http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
*[http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
*[http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
*[http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
*[http://guides.rubyonrails.org/testing.html Testing in Rails] 
*[http://guides.rubyonrails.org/migrations.html Database Migrations] 
<references />

== Further Reading ==

*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-18T22:11:51Z

Mknayak: /* How Rails MVC Works */

= MVC Architecture Structure In Ruby on Rails =

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces agile web development. Rails framework leverages the features of the Ruby language. Ruby is a dynamically typed, object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|frame|center| MVC Flow Diagram]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, JSON. The view does not do any processing, but simply acts as the presentation layer, displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers need not know of the underlying architecture, and are only concerned with the model structure.
 

== How Rails MVC Works ==
[[File:wiki.PNG|center|frame| MVC Architecture working and control flow]]

MVC Architecture working can be explained as follows:
The model, view and controller are referred to as Active Record, Action View and Action Controller respectively here.

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it’s the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. We need to keep as much Ruby code out of the views as possible, so helpers are mainly for use in that context. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices.

There are some types of applications in which Ruby on Rails Architecture is not suitable:

#Sites that depend on large amount of existing code or legacy code or legacy databases. 
#Requirements where dozens or hundreds of websites are residing in a single server. 
#Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

*[http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
*[http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
*[http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
*[http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
*[http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
*[http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
*[http://guides.rubyonrails.org/testing.html Testing in Rails] 
*[http://guides.rubyonrails.org/migrations.html Database Migrations] 
<references />

== Further Reading ==

*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-18T22:11:37Z

Mknayak: /* How Rails MVC Works */

= MVC Architecture Structure In Ruby on Rails =

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces agile web development. Rails framework leverages the features of the Ruby language. Ruby is a dynamically typed, object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|frame|center| MVC Flow Diagram]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, JSON. The view does not do any processing, but simply acts as the presentation layer, displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers need not know of the underlying architecture, and are only concerned with the model structure.
 

== How Rails MVC Works ==
[[File:wiki.PNG|frame| MVC Architecture working and control flow]]

MVC Architecture working can be explained as follows:
The model, view and controller are referred to as Active Record, Action View and Action Controller respectively here.

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it’s the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. We need to keep as much Ruby code out of the views as possible, so helpers are mainly for use in that context. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices.

There are some types of applications in which Ruby on Rails Architecture is not suitable:

#Sites that depend on large amount of existing code or legacy code or legacy databases. 
#Requirements where dozens or hundreds of websites are residing in a single server. 
#Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

*[http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
*[http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
*[http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
*[http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
*[http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
*[http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
*[http://guides.rubyonrails.org/testing.html Testing in Rails] 
*[http://guides.rubyonrails.org/migrations.html Database Migrations] 
<references />

== Further Reading ==

*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-18T22:11:02Z

Mknayak: /* How Rails MVC Works */

= MVC Architecture Structure In Ruby on Rails =

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces agile web development. Rails framework leverages the features of the Ruby language. Ruby is a dynamically typed, object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|frame|center| MVC Flow Diagram]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, JSON. The view does not do any processing, but simply acts as the presentation layer, displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers need not know of the underlying architecture, and are only concerned with the model structure.
 

== How Rails MVC Works ==
[[File:wiki.PNG]]
The model, view and controller are referred to as Active Record, Action View and Action Controller respectively here.
MVC Architecture working can be explained as follows:

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it’s the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. We need to keep as much Ruby code out of the views as possible, so helpers are mainly for use in that context. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices.

There are some types of applications in which Ruby on Rails Architecture is not suitable:

#Sites that depend on large amount of existing code or legacy code or legacy databases. 
#Requirements where dozens or hundreds of websites are residing in a single server. 
#Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

*[http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
*[http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
*[http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
*[http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
*[http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
*[http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
*[http://guides.rubyonrails.org/testing.html Testing in Rails] 
*[http://guides.rubyonrails.org/migrations.html Database Migrations] 
<references />

== Further Reading ==

*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-18T21:41:28Z

Mknayak: /* Pitfalls of the Ruby on Rails Architecture */

= MVC Architecture Structure In Ruby on Rails =

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces agile web development. Rails framework leverages the features of the Ruby language. Ruby is a dynamically typed, object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|frame|center| MVC Flow Diagram]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, JSON. The view does not do any processing, but simply acts as the presentation layer, displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers need not know of the underlying architecture, and are only concerned with the model structure.
 

== How Rails MVC Works ==
[[File:wiki.PNG]]

MVC Architecture working can be explained as follows:

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it’s the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. We need to keep as much Ruby code out of the views as possible, so helpers are mainly for use in that context. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices.

There are some types of applications in which Ruby on Rails Architecture is not suitable:

#Sites that depend on large amount of existing code or legacy code or legacy databases. 
#Requirements where dozens or hundreds of websites are residing in a single server. 
#Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

*[http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
*[http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
*[http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
*[http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
*[http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
*[http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
*[http://guides.rubyonrails.org/testing.html Testing in Rails] 
*[http://guides.rubyonrails.org/migrations.html Database Migrations] 
<references />

== Further Reading ==

*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-18T21:38:50Z

Mknayak: /* What is MVC */

= MVC Architecture Structure In Ruby on Rails =

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces agile web development. Rails framework leverages the features of the Ruby language. Ruby is a dynamically typed, object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|frame|center| MVC Flow Diagram]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, JSON. The view does not do any processing, but simply acts as the presentation layer, displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers need not know of the underlying architecture, and are only concerned with the model structure.
 

== How Rails MVC Works ==
[[File:wiki.PNG]]

MVC Architecture working can be explained as follows:

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it’s the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. We need to keep as much Ruby code out of the views as possible, so helpers are mainly for use in that context. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices.

There are some types of applications in which Ruby on Rails Architecture is not suitable:

1.Static web sites. 
2.Sites that depend on large amount of existing code or legacy code or legacy databases. 
3.Requirements where dozens or hundreds of websites are residing in a single server. 
4.Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

*[http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
*[http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
*[http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
*[http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
*[http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
*[http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
*[http://guides.rubyonrails.org/testing.html Testing in Rails] 
*[http://guides.rubyonrails.org/migrations.html Database Migrations] 
<references />

== Further Reading ==

*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-18T21:37:41Z

Mknayak: /* References */

= MVC Architecture Structure In Ruby on Rails =

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces agile web development. Rails framework leverages the features of the Ruby language. Ruby is a dynamically typed, object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|frame|center| MVC Flow Diagram <ref>MVC Flow Diagram</ref>]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, JSON. The view does not do any processing, but simply acts as the presentation layer, displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers need not know of the underlying architecture, and are only concerned with the model structure.
 

== How Rails MVC Works ==
[[File:wiki.PNG]]

MVC Architecture working can be explained as follows:

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it’s the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. We need to keep as much Ruby code out of the views as possible, so helpers are mainly for use in that context. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices.

There are some types of applications in which Ruby on Rails Architecture is not suitable:

1.Static web sites. 
2.Sites that depend on large amount of existing code or legacy code or legacy databases. 
3.Requirements where dozens or hundreds of websites are residing in a single server. 
4.Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

*[http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
*[http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
*[http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
*[http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
*[http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
*[http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
*[http://guides.rubyonrails.org/testing.html Testing in Rails] 
*[http://guides.rubyonrails.org/migrations.html Database Migrations] 
<references />

== Further Reading ==

*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-18T21:36:11Z

Mknayak: /* What is MVC */

= MVC Architecture Structure In Ruby on Rails =

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces agile web development. Rails framework leverages the features of the Ruby language. Ruby is a dynamically typed, object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|frame|center| MVC Flow Diagram <ref>MVC Flow Diagram</ref>]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, JSON. The view does not do any processing, but simply acts as the presentation layer, displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers need not know of the underlying architecture, and are only concerned with the model structure.
 

== How Rails MVC Works ==
[[File:wiki.PNG]]

MVC Architecture working can be explained as follows:

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it’s the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. We need to keep as much Ruby code out of the views as possible, so helpers are mainly for use in that context. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices.

There are some types of applications in which Ruby on Rails Architecture is not suitable:

1.Static web sites. 
2.Sites that depend on large amount of existing code or legacy code or legacy databases. 
3.Requirements where dozens or hundreds of websites are residing in a single server. 
4.Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

*[http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
*[http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
*[http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
*[http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
*[http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
*[http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
*[http://guides.rubyonrails.org/testing.html Testing in Rails] 
*[http://guides.rubyonrails.org/migrations.html Database Migrations] 

== Further Reading ==

*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-18T21:33:12Z

Mknayak: /* What is MVC */

= MVC Architecture Structure In Ruby on Rails =

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces agile web development. Rails framework leverages the features of the Ruby language. Ruby is a dynamically typed, object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|center| MVC Flow Diagram]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, JSON. The view does not do any processing, but simply acts as the presentation layer, displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers need not know of the underlying architecture, and are only concerned with the model structure.
 

== How Rails MVC Works ==
[[File:wiki.PNG]]

MVC Architecture working can be explained as follows:

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it’s the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. We need to keep as much Ruby code out of the views as possible, so helpers are mainly for use in that context. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices.

There are some types of applications in which Ruby on Rails Architecture is not suitable:

1.Static web sites. 
2.Sites that depend on large amount of existing code or legacy code or legacy databases. 
3.Requirements where dozens or hundreds of websites are residing in a single server. 
4.Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

*[http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
*[http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
*[http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
*[http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
*[http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
*[http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
*[http://guides.rubyonrails.org/testing.html Testing in Rails] 
*[http://guides.rubyonrails.org/migrations.html Database Migrations] 

== Further Reading ==

*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-18T21:25:22Z

Mknayak: /* Further Reading */

= MVC Architecture Structure In Ruby on Rails =

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces agile web development. Rails framework leverages the features of the Ruby language. Ruby is a dynamically typed, object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|center]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, JSON. The view does not do any processing, but simply acts as the presentation layer, displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers need not know of the underlying architecture, and are only concerned with the model structure.
 

== How Rails MVC Works ==
[[File:wiki.PNG]]

MVC Architecture working can be explained as follows:

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it’s the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. We need to keep as much Ruby code out of the views as possible, so helpers are mainly for use in that context. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices.

There are some types of applications in which Ruby on Rails Architecture is not suitable:

1.Static web sites. 
2.Sites that depend on large amount of existing code or legacy code or legacy databases. 
3.Requirements where dozens or hundreds of websites are residing in a single server. 
4.Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

*[http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
*[http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
*[http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
*[http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
*[http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
*[http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
*[http://guides.rubyonrails.org/testing.html Testing in Rails] 
*[http://guides.rubyonrails.org/migrations.html Database Migrations] 

== Further Reading ==

*[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
*[http://guides.rubyonrails.org/routing.html Routing in Rails] 
*[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
*[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]

CSC/ECE 517 Fall 2013/ch1 1w27 ma

2013-09-18T21:24:57Z

Mknayak: /* References */

= MVC Architecture Structure In Ruby on Rails =

The aim of this wiki is to explain the explain the different components of a Rails application. It is directed towards a novice user who can read and get an overview, '''not''' the details of any particular kind of component. In depth discussion links are made available in the further reading section.

== Introduction ==

[http://rubyonrails.org/ Ruby on Rails (RoR)] is open source web framework that is focused on productivity and enforces agile web development. Rails framework leverages the features of the Ruby language. Ruby is a dynamically typed, object-oriented, scripting language that was designed to have an elegant syntax and made as human readable as possible.

The Ruby on Rails framework was designed for database-backed web applications. In order to make the development process faster, Ruby on Rails uses conventions and assumptions which eliminates configuration code and increases productivity. Many tasks like email management, object-database mappers, file structures, code generation etc are built in.

== What is MVC ==

MVC stands for [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model-View-Controller] and is a design pattern and was developed in 1979 by [http://en.wikipedia.org/wiki/Trygve_Reenskaug Trygve Reenskaug]. MVC dictates that the system be split into three distinct parts, a Model, View and Controller. These correspond to the business logic, the presentation logic and the application flow respectively. This approach organizes the code into separate components, thereby achieving separation of concerns and facilitating maintainability.

[[File:Mvc process.png|center]]

=== Model ===
: The Model generally contains the data for the application and is usually linked to a database back-end. It contains the application state, validation and also the business logic. A central component of Rails is the class [http://guides.rubyonrails.org/active_record_querying.html ActiveRecord], which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Models in Rails inherit this class.

:Rails provides tools to implement the [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] functionality with zero-configuration. CRUD allows creating, reading, updating and deleting records from the database through ruby objects. An model object in Rails represents a row in a database table. Additionally, Rails provides advance search capabilities and the ability to create relationships or associations between models. The model has no knowledge of the user interfaces [the view].

=== View ===
:The view refers to the interface that is presented to the end-user and includes HTML, CSS, XML, Javascript, JSON. The view does not do any processing, but simply acts as the presentation layer, displaying the application data. Views in Rails consist of '''''.erb''''' files that combines pure HTML with embedded Ruby code.

=== Controller ===
:The controller receives events from the outside world [ or through some view]. It is the facility within the application that directs traffic. It interacts with the model and redirects to the appropriate view. The controller queries the models for specific data, and also organizes that data (searching, sorting, massaging it) into a form that fits the needs of a given view. In Rails, controllers should descend from '''ApplicationController''' which itself descends from [http://api.rubyonrails.org/classes/ActionController/Base.html ActionController::Base]

Thus the decoupled nature of MVC gives us more flexibility and allows us to easily maintain our application. For example, we can have multiple possible views for the same model and can switch between them if required. Also, view developers need not know of the underlying architecture, and are only concerned with the model structure.
 

== How Rails MVC Works ==
[[File:wiki.PNG]]

MVC Architecture working can be explained as follows:

:1. The browser makes a request, such as http://myblog.com/videos/show/10

:2. The web server receives the request. It uses routes to find out which controller to use. The default route pattern is '''''/controller/action/id''''' as defined in '''''config/routes.rb'''''. In this case, it’s the '''''video''''' controller, method '''''show''''', id '''''10'''''. Controllers do the work of parsing user requests, data submissions, cookies, sessions. In this case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 10, and will eventually display it to the user.

:3.The ''' Model(ActiveRecord)''' is implemented in '''ActiveRecord''' library which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records.

:4. In this case, the model retrieves video 10 from the database.

:5. Model sends the retrieved data ie video 10 in this case to the controller.

:6. The '''Views(ActionView)''' subsystem is implemented in ActionView library which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. In our example, the controller gives video 10 to the '''''show''''' view.

:7. The show view generates the HTML: divs, tables, text, descriptions, footers, etc and returns it to the controller.

:8. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The controller subsystem is implemented in '''ActionController''' which is a data broker sitting between '''ActiveRecord''' (the database interface) and '''ActionView''' (the presentation engine). The server combines the raw data into a proper HTTP response and sends it to the user's browser.

== Directory Structure & Components ==
The primary components of Rails are
* Application components like model, view, controller, helpers
* Environment & Routing Configuration
* Database Migration Components
* Test classes

Now we look at how these components are organised into different directories. The default directory structure of a generated Rails application is as follows:
<pre>
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
</pre>

==== app/ ====

This folder organizes the different application components. These include view (views and helpers), controller (controllers), and the backend business logic (models).
There are the following sub-directories

*'''app/controllers:''' This is the sub-directory where Rails looks for the controller classes.

*'''app/models:''' The directory for the models

*'''app/view:''' The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.

*'''app/view/layouts:''' Layouts directory contains the template files for layouts to be used with views. Examples of layouts are the common header/footer for the views.

*'''app/mailers:''' This directory contains all the mailer files used to send emails. The [http://guides.rubyonrails.org/action_mailer_basics.html ActionMailer] module in Rails can handle simple text or complex rich-format emails. Also it has common tasks built-in, such as, sending out forgotten passwords, welcome messages, and fulfilling any other written-communication’s need.

*'''app/helpers:''' These are the helper classes used to assist the MVC classes. We need to keep as much Ruby code out of the views as possible, so helpers are mainly for use in that context. Helpers are the only methods one can access in the views, other than instance methods for an instance you have access to. Helpers make it possible to keep rest of the MVC code uncluttered.

*'''app/assets:''' The assets folder has sub-directories to store images, javascripts and stylesheets. Rails has an asset pipeline which concatenates and minifies JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
 
----

==== config/ ====
This directory contains the configuration code that the application needs. This includes database configuration, environment structure , routing of incoming web requests.

*'''config/environments:''' It is possible to execute some environment specific code in Rails. Rails automatically detects your current environment [development, test or production] and executes the environment file in this directory. For example, it will run '''''config/environments/development.rb''''' for the development environment. Thus we can tailor the behavior of the three Rails environments for test, development, and deployment with files in the environments directory.

*'''config/initializers:''' Any Ruby file stored in this directory is considered to be an initializer. It holds configuration settings that should be made after all of the frameworks and gems are loaded. Initializers can be further organised into sub-directories. If there are any ordering dependencies for the initializers,we can control the load order by naming. The initializers are run in alphabetical order.

*'''routes.rb:''' The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. Thus it recognizes URLs and dispatches them to a controller's action. The routes.rb file contains the rules .

 
----

==== db/ ====

Usually, your Rails application will have model objects that access relational database tables. You can manage the relational database with scripts you create and place in this directory.

*'''db/migrate:''' Has all the [http://guides.rubyonrails.org/migrations.html migrations] that you created. Migrations are a convenient way to alter your database schema over time in a consistent and easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.

*'''schema.rb:''' It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduct the schema just from the migrations alone. It is used by the tests to populate the database schema.

*'''seeds.rb:''' The purpose of seed data is to [http://en.wikipedia.org/wiki/Bootstrapping bootstrap] your database. Thus in this file, we initialize the database with default values. For example, things like administrative accounts, or other data that's necessary to run your application for the first time. One shouldn't add anything to a seeds.rb file that isn't necessary to bootstrap your database or its relations
 
----

==== test/ ====
The tests you write and those Rails creates for you all go here. You'll see a sub-directory for unit tests (unit), fixtures (fixtures), and functional tests (functional).
There are the following sub-directories

*'''test/unit:''' Unit testing is a testing technique to validate that individual “units” of code are working properly. A “unit” refers to the smallest testable part of the code. When unit testing, we are not interested in how all the units fit together, just in make sure that each unit is functioning properly on its own.

*'''test/fixtures:''' Fixtures are a way of organizing test data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. When you run ''''''rails generate model'''''' to create a new model, fixture stubs will be automatically created and placed in this directory.

*'''test/functional:''' Functional tests live inside of the test/functional directory. These tests are designed to exercise your controllers.

*'''test/integration:''' To write an integration test, standard convention is to put them into a test/integration directory. Whereas unit tests exercise models and functional tests focus on single actions within a specific controller, integration tests are meant to test complete workflows, that likely step through multiple actions across one or more controllers.

*'''test/performance:''' Rails performance tests are a special type of integration tests, designed for bench-marking and profiling the test code. With performance tests, you can determine where your application’s memory or speed problems are coming from, and get a more in-depth picture of those problems.
 
----

==== Other Directories ====
*'''public:''' This directory contains static files and compiled assets, such as JavaScript files (public/javascripts), graphics (public/images), stylesheets (public/stylesheets), and HTML files (public). The files in this directory are accessible by anyone visiting the site, irrespective of authentication. Error pages (404) are usually stored here

*'''tmp:''' Temporary files are stored here.

*'''vendor:''' This folder contains plugins, gems & libraries provided by third-party vendors. Example: database utilities library

*'''script:''' This directory holds scripts to launch and manage the various tools that you'll use with Rails.

*'''lib:''' For library [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html modules].

*'''log:''' Error logs for the server (server.log) and each Rails environment (development.log, test.log, and production.log).

*'''doc:''' Rails can generate the documentation for your code automatically, if you provide comments in a certain expected format in your code. The generated documentation is placed in this directory.
 
----

==== Gemfile ====
[http://en.wikipedia.org/wiki/RubyGems Gems] are Ruby software packages available online. The gemfile is a list of all gems that you want to include in the project. The bundler tool uses the gem file to install, update, remove and otherwise manage existing gems.It is possible to group gems in ''':development, :test, :assets & :production''' groups and Rails will know when to include the gems.

 
----

==== Rakefile ====
The [http://rake.rubyforge.org/doc/rakefile_rdoc.html Rakefile] is similar to [http://capone.mtsu.edu/csdept/FacilitiesAndResources/make.htm Unix Makefile] which helps with building, packaging and testing the Rails code. This will be used by rake utility supplied along with Ruby installation.

 
----

==== README ====
This file contains a basic detail about Rail Application and description of the directory structure explained above
 

== Pitfalls of the Ruby on Rails Architecture ==

=== Build on interpreted language ===
:As Rails is built on the top of the Ruby language, it inherits its goodness and weakness as well. Ruby is totally object oriented and a dynamic scripting language with an elegant syntax. As it is an interpreted language it is slower than other languages that are compiled like Java or C++. In most cases, this difference in speed is not a problem but the performance starts to degrade when the web application needs to scale to millions of concurrent users.

=== Not suited for high concurrency ===
:The Ruby language is not suited for high concurrency applications, because it is not optimized for speed computing. Ruby was designed to be used for rapid development. It does not have good thread support and has trouble dealing with long-lived processes. Another shortcoming is that Ruby’s garbage collector cannot be compared to that of Java. Thus each process requires much more memory.

=== Deployment concerns ===
:Although not an architectural flaw, a web application on Ruby on Rails could be harder to deploy than sites that are using more common technologies, such as PHP. That’s because not all the hosting providers support Rails, but the support for Rails is increasing.

=== Scalability concerns ===
:Often there are talks about scalability issues in Rails. Developers claim that when dealing with large scale application, the ORM layer turns out to be a bottleneck. As stated above, the lack of good thread support is also a contributing factor. Caching can mitigate some of the speed concerns.

=== Decision of convention over configuration ===
:The Rails architecture sacrifices some flexibility in configuration to increase productivity based on conventions that are considered best practices.

There are some types of applications in which Ruby on Rails Architecture is not suitable:

1.Static web sites. 
2.Sites that depend on large amount of existing code or legacy code or legacy databases. 
3.Requirements where dozens or hundreds of websites are residing in a single server. 
4.Very large-scale web applications (millions of concurrent users) that need to deliver high-performance. 

== References ==

*[http://www.ibm.com/developerworks/linux/library/l-rubyrails/ Ruby on Rails for web application] 
*[http://santhoshthepro.in/rails-directory-structure Rails Directory structure] 
*[http://www.tutorialspoint.com/ruby-on-rails/ Ruby on Rails Tutorial] 
*[http://www.computerworld.com/s/article/9060861/Ruby_on_Rails_routing_demystified?pageNumber=1 Routing Demytified] 
*[http://blog.iandavis.com/2008/12/09/ What-are-the-benefits-of-MVC] 
*[http://adrianmejia.com/blog/2011/08/11/ruby-on-rails-architectural-design/ Ruby-on-rails-architectural-design] 
*[http://guides.rubyonrails.org/testing.html Testing in Rails] 
*[http://guides.rubyonrails.org/migrations.html Database Migrations] 

== Further Reading ==

[http://guides.rubyonrails.org/initialization.html Rails Initialization Process] 
[http://guides.rubyonrails.org/routing.html Routing in Rails] 
[http://www.informit.com/articles/article.aspx?p=1087656&seqNum=5 Routing Explained] 
[http://c2.com/cgi/wiki?ModelViewController Model-View-Controller Guide]