Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:45:21Z

Nmanjun3: /* Also see */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=
Testing plays a major role in the software development cycle. It is a well known fact that mandatory testing of every functionality implemented be done so as to ensure that the code does not break when in production. Testing can be done in four main stages: Unit testing (individual code modules are tested for flaws and re-coded if any errors are found), Integration testing (various interacting modules are put together piece by piece to ensure that seamless integration exists among them), System testing (the system is tested as a whole after it has been fully integrated) and Acceptance testing (potential users test the system for flaws in design or execution and to see if the product matches their expectation).

This article focuses on Unit testing by following the Test Driven Development approach for Ruby using RSpec framework as explained in this [https://www.youtube.com/watch?v=oFX1KPNRruA&feature=relmfu SaaS] video.

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] <sup>[http://rspec.info/]</sup>. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework <sup>[http://en.wikipedia.org/wiki/RSpec]</sup>. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host <sup>[http://en.wikipedia.org/wiki/Domain-specific_language]</sup>.
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.

==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step <sup>[http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/]</sup>. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.

=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=
#http://rspec.info/
#http://en.wikipedia.org/wiki/RSpec
#http://en.wikipedia.org/wiki/Domain-specific_language
#http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/

=Also see=
*https://www.youtube.com/watch?v=oFX1KPNRruA&feature=relmfu
*http://en.wikipedia.org/wiki/Software_quality_assurance
*http://en.wikipedia.org/wiki/Test-driven_development
*http://en.wikipedia.org/wiki/Regular_expression
*http://en.wikipedia.org/wiki/SQL
*http://en.wikipedia.org/wiki/Ruby_%28programming_language%29
*http://en.wikipedia.org/wiki/Behavior-driven_development
*http://jbehave.org/
*http://en.wikipedia.org/wiki/Domain-specific_language
*http://guides.rubyonrails.org/command_line.html
*http://en.wikipedia.org/wiki/Cucumber_%28software%29
*http://pastebin.com/kJxjwSF6

=Other Interesting Links=
*[http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/ Newbies guide to TDD]
*[http://www.codeproject.com/Articles/9099/The-30-Minute-Regex-Tutorial The 30 minute Regex tutorial]
*[http://www.andrejkoelewijn.com/wp/2008/10/27/sql-is-a-dsl/ SQL is a DSL]
*[https://www.relishapp.com/rspec RSpec]
*[https://www.relishapp.com/rspec/rspec-rails/v/2-0/docs/helper-specs/helper-spec Spec helper]

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:44:30Z

Nmanjun3: /* References */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=
Testing plays a major role in the software development cycle. It is a well known fact that mandatory testing of every functionality implemented be done so as to ensure that the code does not break when in production. Testing can be done in four main stages: Unit testing (individual code modules are tested for flaws and re-coded if any errors are found), Integration testing (various interacting modules are put together piece by piece to ensure that seamless integration exists among them), System testing (the system is tested as a whole after it has been fully integrated) and Acceptance testing (potential users test the system for flaws in design or execution and to see if the product matches their expectation).

This article focuses on Unit testing by following the Test Driven Development approach for Ruby using RSpec framework as explained in this [https://www.youtube.com/watch?v=oFX1KPNRruA&feature=relmfu SaaS] video.

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] <sup>[http://rspec.info/]</sup>. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework <sup>[http://en.wikipedia.org/wiki/RSpec]</sup>. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host <sup>[http://en.wikipedia.org/wiki/Domain-specific_language]</sup>.
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.

==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step <sup>[http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/]</sup>. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.

=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=
#http://rspec.info/
#http://en.wikipedia.org/wiki/RSpec
#http://en.wikipedia.org/wiki/Domain-specific_language
#http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/

=Also see=
#https://www.youtube.com/watch?v=oFX1KPNRruA&feature=relmfu
#http://en.wikipedia.org/wiki/Software_quality_assurance
#http://en.wikipedia.org/wiki/Test-driven_development
#http://en.wikipedia.org/wiki/Regular_expression
#http://en.wikipedia.org/wiki/SQL
#http://en.wikipedia.org/wiki/Ruby_%28programming_language%29
#http://en.wikipedia.org/wiki/Behavior-driven_development
#http://jbehave.org/
#http://en.wikipedia.org/wiki/Domain-specific_language
#http://guides.rubyonrails.org/command_line.html
#http://en.wikipedia.org/wiki/Cucumber_%28software%29
#http://pastebin.com/kJxjwSF6

=Other Interesting Links=
*[http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/ Newbies guide to TDD]
*[http://www.codeproject.com/Articles/9099/The-30-Minute-Regex-Tutorial The 30 minute Regex tutorial]
*[http://www.andrejkoelewijn.com/wp/2008/10/27/sql-is-a-dsl/ SQL is a DSL]
*[https://www.relishapp.com/rspec RSpec]
*[https://www.relishapp.com/rspec/rspec-rails/v/2-0/docs/helper-specs/helper-spec Spec helper]

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:41:14Z

Nmanjun3: /* RSpec */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=
Testing plays a major role in the software development cycle. It is a well known fact that mandatory testing of every functionality implemented be done so as to ensure that the code does not break when in production. Testing can be done in four main stages: Unit testing (individual code modules are tested for flaws and re-coded if any errors are found), Integration testing (various interacting modules are put together piece by piece to ensure that seamless integration exists among them), System testing (the system is tested as a whole after it has been fully integrated) and Acceptance testing (potential users test the system for flaws in design or execution and to see if the product matches their expectation).

This article focuses on Unit testing by following the Test Driven Development approach for Ruby using RSpec framework as explained in this [https://www.youtube.com/watch?v=oFX1KPNRruA&feature=relmfu SaaS] video.

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] <sup>[http://rspec.info/]</sup>. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework <sup>[http://en.wikipedia.org/wiki/RSpec]</sup>. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host <sup>[http://en.wikipedia.org/wiki/Domain-specific_language]</sup>.
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.

==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step <sup>[http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/]</sup>. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.

=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=
#https://www.youtube.com/watch?v=oFX1KPNRruA&feature=relmfu
#http://en.wikipedia.org/wiki/Software_quality_assurance
#http://en.wikipedia.org/wiki/Test-driven_development
#http://en.wikipedia.org/wiki/Domain-specific_language
#http://en.wikipedia.org/wiki/Regular_expression
#http://en.wikipedia.org/wiki/SQL
#http://en.wikipedia.org/wiki/RSpec
#http://en.wikipedia.org/wiki/Ruby_%28programming_language%29
#http://rspec.info/
#http://en.wikipedia.org/wiki/Behavior-driven_development
#http://jbehave.org/
#http://en.wikipedia.org/wiki/Domain-specific_language
#http://guides.rubyonrails.org/command_line.html
#http://en.wikipedia.org/wiki/Cucumber_%28software%29
#http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/
#http://pastebin.com/kJxjwSF6

=Other Interesting Links=
*[http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/ Newbies guide to TDD]
*[http://www.codeproject.com/Articles/9099/The-30-Minute-Regex-Tutorial The 30 minute Regex tutorial]
*[http://www.andrejkoelewijn.com/wp/2008/10/27/sql-is-a-dsl/ SQL is a DSL]
*[https://www.relishapp.com/rspec RSpec]
*[https://www.relishapp.com/rspec/rspec-rails/v/2-0/docs/helper-specs/helper-spec Spec helper]

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:40:30Z

Nmanjun3: /* The code we wish we had */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=
Testing plays a major role in the software development cycle. It is a well known fact that mandatory testing of every functionality implemented be done so as to ensure that the code does not break when in production. Testing can be done in four main stages: Unit testing (individual code modules are tested for flaws and re-coded if any errors are found), Integration testing (various interacting modules are put together piece by piece to ensure that seamless integration exists among them), System testing (the system is tested as a whole after it has been fully integrated) and Acceptance testing (potential users test the system for flaws in design or execution and to see if the product matches their expectation).

This article focuses on Unit testing by following the Test Driven Development approach for Ruby using RSpec framework as explained in this [https://www.youtube.com/watch?v=oFX1KPNRruA&feature=relmfu SaaS] video.

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] <sup>[http://rspec.info/]</sup>. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by <sup>[http://jbehave.org/ JBehave]</sup> which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.

==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step <sup>[http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/]</sup>. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.

=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=
#https://www.youtube.com/watch?v=oFX1KPNRruA&feature=relmfu
#http://en.wikipedia.org/wiki/Software_quality_assurance
#http://en.wikipedia.org/wiki/Test-driven_development
#http://en.wikipedia.org/wiki/Domain-specific_language
#http://en.wikipedia.org/wiki/Regular_expression
#http://en.wikipedia.org/wiki/SQL
#http://en.wikipedia.org/wiki/RSpec
#http://en.wikipedia.org/wiki/Ruby_%28programming_language%29
#http://rspec.info/
#http://en.wikipedia.org/wiki/Behavior-driven_development
#http://jbehave.org/
#http://en.wikipedia.org/wiki/Domain-specific_language
#http://guides.rubyonrails.org/command_line.html
#http://en.wikipedia.org/wiki/Cucumber_%28software%29
#http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/
#http://pastebin.com/kJxjwSF6

=Other Interesting Links=
*[http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/ Newbies guide to TDD]
*[http://www.codeproject.com/Articles/9099/The-30-Minute-Regex-Tutorial The 30 minute Regex tutorial]
*[http://www.andrejkoelewijn.com/wp/2008/10/27/sql-is-a-dsl/ SQL is a DSL]
*[https://www.relishapp.com/rspec RSpec]
*[https://www.relishapp.com/rspec/rspec-rails/v/2-0/docs/helper-specs/helper-spec Spec helper]

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:39:53Z

Nmanjun3: /* RSpec */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=
Testing plays a major role in the software development cycle. It is a well known fact that mandatory testing of every functionality implemented be done so as to ensure that the code does not break when in production. Testing can be done in four main stages: Unit testing (individual code modules are tested for flaws and re-coded if any errors are found), Integration testing (various interacting modules are put together piece by piece to ensure that seamless integration exists among them), System testing (the system is tested as a whole after it has been fully integrated) and Acceptance testing (potential users test the system for flaws in design or execution and to see if the product matches their expectation).

This article focuses on Unit testing by following the Test Driven Development approach for Ruby using RSpec framework as explained in this [https://www.youtube.com/watch?v=oFX1KPNRruA&feature=relmfu SaaS] video.

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] <sup>[http://rspec.info/]</sup>. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by <sup>[http://jbehave.org/ JBehave]</sup> which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.

==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step [http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/]. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.

=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=
#https://www.youtube.com/watch?v=oFX1KPNRruA&feature=relmfu
#http://en.wikipedia.org/wiki/Software_quality_assurance
#http://en.wikipedia.org/wiki/Test-driven_development
#http://en.wikipedia.org/wiki/Domain-specific_language
#http://en.wikipedia.org/wiki/Regular_expression
#http://en.wikipedia.org/wiki/SQL
#http://en.wikipedia.org/wiki/RSpec
#http://en.wikipedia.org/wiki/Ruby_%28programming_language%29
#http://rspec.info/
#http://en.wikipedia.org/wiki/Behavior-driven_development
#http://jbehave.org/
#http://en.wikipedia.org/wiki/Domain-specific_language
#http://guides.rubyonrails.org/command_line.html
#http://en.wikipedia.org/wiki/Cucumber_%28software%29
#http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/
#http://pastebin.com/kJxjwSF6

=Other Interesting Links=
*[http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/ Newbies guide to TDD]
*[http://www.codeproject.com/Articles/9099/The-30-Minute-Regex-Tutorial The 30 minute Regex tutorial]
*[http://www.andrejkoelewijn.com/wp/2008/10/27/sql-is-a-dsl/ SQL is a DSL]
*[https://www.relishapp.com/rspec RSpec]
*[https://www.relishapp.com/rspec/rspec-rails/v/2-0/docs/helper-specs/helper-spec Spec helper]

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:38:42Z

Nmanjun3: /* Other Interesting Links */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=
Testing plays a major role in the software development cycle. It is a well known fact that mandatory testing of every functionality implemented be done so as to ensure that the code does not break when in production. Testing can be done in four main stages: Unit testing (individual code modules are tested for flaws and re-coded if any errors are found), Integration testing (various interacting modules are put together piece by piece to ensure that seamless integration exists among them), System testing (the system is tested as a whole after it has been fully integrated) and Acceptance testing (potential users test the system for flaws in design or execution and to see if the product matches their expectation).

This article focuses on Unit testing by following the Test Driven Development approach for Ruby using RSpec framework as explained in this [https://www.youtube.com/watch?v=oFX1KPNRruA&feature=relmfu SaaS] video.

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.

==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step [http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/]. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.

=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=
#https://www.youtube.com/watch?v=oFX1KPNRruA&feature=relmfu
#http://en.wikipedia.org/wiki/Software_quality_assurance
#http://en.wikipedia.org/wiki/Test-driven_development
#http://en.wikipedia.org/wiki/Domain-specific_language
#http://en.wikipedia.org/wiki/Regular_expression
#http://en.wikipedia.org/wiki/SQL
#http://en.wikipedia.org/wiki/RSpec
#http://en.wikipedia.org/wiki/Ruby_%28programming_language%29
#http://rspec.info/
#http://en.wikipedia.org/wiki/Behavior-driven_development
#http://jbehave.org/
#http://en.wikipedia.org/wiki/Domain-specific_language
#http://guides.rubyonrails.org/command_line.html
#http://en.wikipedia.org/wiki/Cucumber_%28software%29
#http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/
#http://pastebin.com/kJxjwSF6

=Other Interesting Links=
*[http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/ Newbies guide to TDD]
*[http://www.codeproject.com/Articles/9099/The-30-Minute-Regex-Tutorial The 30 minute Regex tutorial]
*[http://www.andrejkoelewijn.com/wp/2008/10/27/sql-is-a-dsl/ SQL is a DSL]
*[https://www.relishapp.com/rspec RSpec]
*[https://www.relishapp.com/rspec/rspec-rails/v/2-0/docs/helper-specs/helper-spec Spec helper]

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:34:29Z

Nmanjun3: /* References */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=
Testing plays a major role in the software development cycle. It is a well known fact that mandatory testing of every functionality implemented be done so as to ensure that the code does not break when in production. Testing can be done in four main stages: Unit testing (individual code modules are tested for flaws and re-coded if any errors are found), Integration testing (various interacting modules are put together piece by piece to ensure that seamless integration exists among them), System testing (the system is tested as a whole after it has been fully integrated) and Acceptance testing (potential users test the system for flaws in design or execution and to see if the product matches their expectation).

This article focuses on Unit testing by following the Test Driven Development approach for Ruby using RSpec framework as explained in this [https://www.youtube.com/watch?v=oFX1KPNRruA&feature=relmfu SaaS] video.

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.

==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step [http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/]. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.

=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=
#https://www.youtube.com/watch?v=oFX1KPNRruA&feature=relmfu
#http://en.wikipedia.org/wiki/Software_quality_assurance
#http://en.wikipedia.org/wiki/Test-driven_development
#http://en.wikipedia.org/wiki/Domain-specific_language
#http://en.wikipedia.org/wiki/Regular_expression
#http://en.wikipedia.org/wiki/SQL
#http://en.wikipedia.org/wiki/RSpec
#http://en.wikipedia.org/wiki/Ruby_%28programming_language%29
#http://rspec.info/
#http://en.wikipedia.org/wiki/Behavior-driven_development
#http://jbehave.org/
#http://en.wikipedia.org/wiki/Domain-specific_language
#http://guides.rubyonrails.org/command_line.html
#http://en.wikipedia.org/wiki/Cucumber_%28software%29
#http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/
#http://pastebin.com/kJxjwSF6

=Other Interesting Links=
*[http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/ Newbies guide to TDD]
*[http://www.codeproject.com/Articles/9099/The-30-Minute-Regex-Tutorial The 30 minute Regex tutorial]
*[http://www.andrejkoelewijn.com/wp/2008/10/27/sql-is-a-dsl/ SQL is a DSL]

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:33:01Z

Nmanjun3: /* Introduction */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=
Testing plays a major role in the software development cycle. It is a well known fact that mandatory testing of every functionality implemented be done so as to ensure that the code does not break when in production. Testing can be done in four main stages: Unit testing (individual code modules are tested for flaws and re-coded if any errors are found), Integration testing (various interacting modules are put together piece by piece to ensure that seamless integration exists among them), System testing (the system is tested as a whole after it has been fully integrated) and Acceptance testing (potential users test the system for flaws in design or execution and to see if the product matches their expectation).

This article focuses on Unit testing by following the Test Driven Development approach for Ruby using RSpec framework as explained in this [https://www.youtube.com/watch?v=oFX1KPNRruA&feature=relmfu SaaS] video.

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.

==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step [http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/]. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.

=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=
# http://en.wikipedia.org/wiki/Software_quality_assurance
#http://en.wikipedia.org/wiki/Test-driven_development
#http://en.wikipedia.org/wiki/Domain-specific_language
#http://en.wikipedia.org/wiki/Regular_expression
#http://en.wikipedia.org/wiki/SQL
#http://en.wikipedia.org/wiki/RSpec
#http://en.wikipedia.org/wiki/Ruby_%28programming_language%29
#http://rspec.info/
#http://en.wikipedia.org/wiki/Behavior-driven_development
#http://jbehave.org/
#http://en.wikipedia.org/wiki/Domain-specific_language
#http://guides.rubyonrails.org/command_line.html
#http://en.wikipedia.org/wiki/Cucumber_%28software%29
#http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/

=Other Interesting Links=
*[http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/ Newbies guide to TDD]
*[http://www.codeproject.com/Articles/9099/The-30-Minute-Regex-Tutorial The 30 minute Regex tutorial]
*[http://www.andrejkoelewijn.com/wp/2008/10/27/sql-is-a-dsl/ SQL is a DSL]

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:29:21Z

Nmanjun3:

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=
Testing plays a major role in the software development cycle. It is a well known fact that mandatory testing of every functionality implemented be done so as to ensure that the code does not break when in production. Testing can be done in four main stages: Unit testing (individual code modules are tested for flaws and re-coded if any errors are found), Integration testing (various interacting modules are put together piece by piece to ensure that seamless integration exists among them), System testing (the system is tested as a whole after it has been fully integrated) and Acceptance testing (potential users test the system for flaws in design or execution and to see if the product matches their expectation).

This article focuses on Unit testing by following the Test Driven Development approach for Ruby using RSpec framework.

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.

==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step [http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/]. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.

=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=
# http://en.wikipedia.org/wiki/Software_quality_assurance
#http://en.wikipedia.org/wiki/Test-driven_development
#http://en.wikipedia.org/wiki/Domain-specific_language
#http://en.wikipedia.org/wiki/Regular_expression
#http://en.wikipedia.org/wiki/SQL
#http://en.wikipedia.org/wiki/RSpec
#http://en.wikipedia.org/wiki/Ruby_%28programming_language%29
#http://rspec.info/
#http://en.wikipedia.org/wiki/Behavior-driven_development
#http://jbehave.org/
#http://en.wikipedia.org/wiki/Domain-specific_language
#http://guides.rubyonrails.org/command_line.html
#http://en.wikipedia.org/wiki/Cucumber_%28software%29
#http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/

=Other Interesting Links=
*[http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/ Newbies guide to TDD]
*[http://www.codeproject.com/Articles/9099/The-30-Minute-Regex-Tutorial The 30 minute Regex tutorial]
*[http://www.andrejkoelewijn.com/wp/2008/10/27/sql-is-a-dsl/ SQL is a DSL]

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:20:21Z

Nmanjun3: /* RSpec */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.

==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step [http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/]. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.

=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=

=Other Interesting Links=
*[http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/ Newbies guide to TDD]
*[http://www.codeproject.com/Articles/9099/The-30-Minute-Regex-Tutorial The 30 minute Regex tutorial]
*[http://www.andrejkoelewijn.com/wp/2008/10/27/sql-is-a-dsl/ SQL is a DSL]

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:20:01Z

Nmanjun3: /* RSpec */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host[http://en.wikipedia.org/wiki/Domain-specific_language].
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.

==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step [http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/]. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.

=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=

=Other Interesting Links=
*[http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/ Newbies guide to TDD]
*[http://www.codeproject.com/Articles/9099/The-30-Minute-Regex-Tutorial The 30 minute Regex tutorial]
*[http://www.andrejkoelewijn.com/wp/2008/10/27/sql-is-a-dsl/ SQL is a DSL]

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:19:26Z

Nmanjun3: /* RSpec */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host.[http://en.wikipedia.org/wiki/Domain-specific_language]
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.

==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step [http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/]. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.

=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=

=Other Interesting Links=
*[http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/ Newbies guide to TDD]
*[http://www.codeproject.com/Articles/9099/The-30-Minute-Regex-Tutorial The 30 minute Regex tutorial]
*[http://www.andrejkoelewijn.com/wp/2008/10/27/sql-is-a-dsl/ SQL is a DSL]

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:16:14Z

Nmanjun3: /* RSpec */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby][http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [2]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host.[3]
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.

==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step[4]. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.

=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=

=Also see=
[http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/ Newbies guide to TDD]
[http://www.codeproject.com/Articles/9099/The-30-Minute-Regex-Tutorial The 30 minute Regex tutorial]
[http://www.andrejkoelewijn.com/wp/2008/10/27/sql-is-a-dsl/ SQL is a DSL]

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:15:25Z

Nmanjun3: /* Features of RSpec */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby][1]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [2]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host.[3]
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.

==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step[4]. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.

=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=

=Also see=

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:14:31Z

Nmanjun3: /* RSpec */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby][1]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [2]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host.[3]
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [ http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.
==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step[4]. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.

=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=

=Also see=

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:13:11Z

Nmanjun3:

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby][1]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/JBehave] which is another BDD testing framework [2]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host.[3]
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [ http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.
==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step[4]. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.
=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=

=Also see=

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:08:20Z

Nmanjun3:

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby][1]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/JBehave] which is another BDD testing framework [2]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host.[3]
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.
==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper[] is a file that RSpec creates as a part of the install step. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.
=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. The spec_helper file which facilitates testing, is installed with RSpec.

=References=

=Also see=

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-23T16:28:45Z

Nmanjun3: /* Features of Unit tests */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=

=Features of Unit tests=
*Fast: Run tests quickly
*Independent: No tests depend on other. So can run any subset of the tests in any order.
*Repeatable: Run N times and get the same result.
*Self-checking: Test can automatically detect if passed. No human checking of output should be required.
*Timely: Written about the same time as the code under test.

=Disadvantages of QA=

=Rspec=

=Conclusion=

=References=

=Also see=

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-22T01:20:13Z

Nmanjun3: Created page with "<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br> =Introduction= =Features of Unit tests= =Disadvantages of QA= =Rspec= =Conclusion= =References=..."

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=

=Features of Unit tests=

=Disadvantages of QA=

=Rspec=

=Conclusion=

=References=

=Also see=

CSC/ECE 517 Fall 2012

2012-10-22T01:19:56Z

Nmanjun3:

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

*[[CSC/ECE 517 Fall 2012/ch1 1w27 ms]]
*[[CSC/ECE 517 Fall 2012/ch1 1w29 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w33 op]]
*[[CSC/ECE 517 Fall 2012/ch1 1w19 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w34 vd]]
*[[CSC/ECE 517 Fall 2012/ch1 1w35 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w30 rp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w58 am]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w47 sk]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w69 mv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w44 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w45 is]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w53 kc]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 ar]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w39 sn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w54 go]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w56 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w64 nn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w66 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w42 js]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w46 sm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w71 gs]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w63 dv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w55 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w57 mp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w52 an]]
*[[CSC/ECE_517_Fall_2012/ch1b 1w38 nm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w60 ac]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w62 rb]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w29 st]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w30 an]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w17 pt]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w31 up]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w9 ms]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w19 is]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w16 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w8 vp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w18 as]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w3 jm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w23 sr]]

CSC/ECE 517 Fall 2012

2012-10-22T01:09:19Z

Nmanjun3: Undo revision 67737 by Nmanjun3 (talk)

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

*[[CSC/ECE 517 Fall 2012/ch1 1w27 ms]]
*[[CSC/ECE 517 Fall 2012/ch1 1w29 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w33 op]]
*[[CSC/ECE 517 Fall 2012/ch1 1w19 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w34 vd]]
*[[CSC/ECE 517 Fall 2012/ch1 1w35 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w30 rp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w58 am]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w47 sk]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w69 mv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w44 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w45 is]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w53 kc]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 ar]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w39 sn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w54 go]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w56 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w64 nn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w66 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w42 js]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w46 sm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w71 gs]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w63 dv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w55 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w57 mp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w52 an]]
*[[CSC/ECE_517_Fall_2012/ch1b 1w38 nm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w60 ac]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w62 rb]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w29 st]]
*[[CSC/ECE 517 Fall 2012/ch 2w30 an]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w17 pt]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w31 up]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w9 ms]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w19 is]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w16 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w8 vp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w18 as]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w3 jm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w23 sr]]

CSC/ECE 517 Fall 2012

2012-10-22T01:00:20Z

Nmanjun3:

CSC/ECE 517 Fall 2012/ch 2w30 an

2012-10-14T19:28:20Z

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big><br>

=Introduction=

=Features of Unit tests=

=Disadvantages of QA=

=Rspec=

=Conclusion=

=References=

=Also see=

CSC/ECE 517 Fall 2012

2012-10-14T19:25:25Z

Nmanjun3:

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

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

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-12T20:14:32Z

Nmanjun3:

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [http://en.wikipedia.org/wiki/Software_as_a_service SaaS] is one such video series made by University of California, Berkley.

=Introduction=

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It gives an overview of MVC responsibilities in a Rails application with the main focus on the creation of controllers and views for a specific model.

=MVC responsibilities=
In Rails, applications are broken into three types of components: models, views, and controllers.

* '''Model''': Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get and manipulate data. Different methods are provided by ''ActiveRecord'' to do that [1]. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

* '''Controller''': In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods [3]. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here, params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling Movie.find. In a real application, this is unsafe and must be handled by an exception since ''params[:id]'' can happen to be a non-existing value and will result in an error. Finally the instance variable ''@movie'' in the controller is going to be available to the view.

* '''View''': Views are responsible for creating response in the browser to display data and allow user interaction [2][3]. In the above example, show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in ''app/view/movies/show.html.erb''. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

=Adding a new controller action to Rails application=
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ''ActionController'' super class [3]. To create a controller, these steps must be followed.
* Add the action method in the appropriate ''app/controllers/*_controller.rb''. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in ''routes.rb''
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in ''app/views/model/action.html.erb''. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the ''app/view/model''. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in ''app/view/movie/index.html.erb''. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

=URI helpers=

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another [4]. In the above mentioned example of a view, there are three helper methods used namely, ''movie_path(movie)'', ''edit_movie_path(movie)'', ''new_movie_path''. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies ''index.html.erb''. Somewhere on that page there will be a link whose argument is movie_path with an argument.

<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be ''movie/:id'' with a ''GET'' method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>

From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route ''GET /movies/:id'' which matches the show action of the movies controller. Further it takes '':id'' and stores as ''params[:id]''. With that ''params[:id]'', appropriate controller action is called.

[[File:Helper_methods.gif‎|700 px|thumb|center|Connecting URIs using helper methods]]

Further the user can return to the list of movies with the help of another URI helper, ''movies_path''. ''movies_path'' with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and ''movies_path'' is a method call.

=Conclusion=
Implementing MVC architecture in Rails application has few advantages. For example it separates models from presentation which in turn helps in implementing better test cases and better UI's for the user [9]. It also separates controller functionality with views which facilitates development of better web interfaces. Also Rails provides an easy way to implement MVC architecture for a user. All these advantages and the fact that MVC can be implemented in an effortless and uncomplicated manner necessitate the use of MVC architecture in Rails application.

=References=
#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#https://class.coursera.org/saas/lecture/preview/index
#http://en.wikibooks.org/wiki/Ruby_on_Rails/Getting_Started/Model-View-Controller
#http://en.wikipedia.org/wiki/Ruby_on_Rails
#http://en.wikipedia.org/wiki/Software_as_a_service
#http://en.wikipedia.org/wiki/Representational_state_transfer
#http://en.wikipedia.org/wiki/Embedded_Ruby
#http://amix.dk/blog/post/19615

=Also see=
#http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
#http://books.google.com/books?id=jMCO096qlRsC&printsec=frontcover&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false
#http://pragprog.com/book/rails4/agile-web-development-with-rails
#http://ruby.railstutorial.org/

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-12T18:08:01Z

Nmanjun3: /* Introduction */

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [http://en.wikipedia.org/wiki/Software_as_a_service SaaS] is one such video series made by University of California, Berkley.

=Introduction=

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It gives an overview of MVC responsibilities in a Rails application with the main focus on the creation of controllers and views for a specific model.

=MVC responsibilities=
In Rails, applications are broken into three types of components: models, views, and controllers.

* '''Model''': Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get and manipulate data. Different methods are provided by ''ActiveRecord'' to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

* '''Controller''': In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here, params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling Movie.find. In a real application, this is unsafe and must be handled by an exception since ''params[:id]'' can happen to be a non-existing value and will result in an error. Finally the instance variable ''@movie'' in the controller is going to be available to the view.

* '''View''': Views are responsible for creating response in the browser to display data and allow user interaction. In the above example, show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in ''app/view/movies/show.html.erb''. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

=Adding a new controller action to Rails application=
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ''ActionController'' super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate ''app/controllers/*_controller.rb''. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in ''routes.rb''
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in ''app/views/model/action.html.erb''. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the ''app/view/model''. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in ''app/view/movie/index.html.erb''. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

=URI helpers=

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, ''movie_path(movie)'', ''edit_movie_path(movie)'', ''new_movie_path''. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies ''index.html.erb''. Somewhere on that page there will be a link whose argument is movie_path with an argument.

<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be ''movie/:id'' with a ''GET'' method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>

From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route ''GET /movies/:id'' which matches the show action of the movies controller. Further it takes '':id'' and stores as ''params[:id]''. With that ''params[:id]'', appropriate controller action is called.

[[File:Helper_methods.gif‎|700 px|thumb|center|Connecting URIs using helper methods]]

Further the user can return to the list of movies with the help of another URI helper, ''movies_path''. ''movies_path'' with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and ''movies_path'' is a method call.

=References=

#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#https://class.coursera.org/saas/lecture/preview/index
#http://en.wikipedia.org/wiki/Ruby_on_Rails
#http://en.wikipedia.org/wiki/Software_as_a_service
#http://en.wikipedia.org/wiki/Representational_state_transfer
#http://en.wikipedia.org/wiki/Embedded_Ruby
#http://pragprog.com/book/rails4/agile-web-development-with-rails
#http://ruby.railstutorial.org/

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-04T01:05:26Z

Nmanjun3: /* MVC responsibilities */

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [http://en.wikipedia.org/wiki/Software_as_a_service SaaS] is one such video series made by University of California, Berkley.

=Introduction=

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

=MVC responsibilities=
In Rails, applications are broken into three types of components: models, views, and controllers.

* '''Model''': Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get and manipulate data. Different methods are provided by ''ActiveRecord'' to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

* '''Controller''': In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since ''params[:id]'' can happen to be a non-existing value and will result in an error. Finally the instance variable ''@movie'' in the controller is going to be available to the view.

* '''View''': Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in ''app/view/movies/show.html.erb''. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

=Adding a new controller action to Rails application=
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ''ActionController'' super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate ''app/controllers/*_controller.rb''. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in ''routes.rb''
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in ''app/views/model/action.html.erb''. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the ''app/view/model''. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in ''app/view/movie/index.html.erb''. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

=URI helpers=

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, ''movie_path(movie)'', ''edit_movie_path(movie)'', ''new_movie_path''. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies ''index.html.erb''. Somewhere on that page there will be a link whose argument is movie_path with an argument.

<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be ''movie/:id'' with a ''GET'' method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>

From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route ''GET /movies/:id'' which matches the show action of the movies controller. Further it takes '':id'' and stores as ''params[:id]''. With that ''params[:id]'', appropriate controller action is called.

[[File:Helper_methods.gif‎|700 px|thumb|center|Connecting URIs using helper methods]]

Further the user can return to the list of movies with the help of another URI helper, ''movies_path''. ''movies_path'' with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and ''movies_path'' is a method call.

=References=

#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#https://class.coursera.org/saas/lecture/preview/index
#http://en.wikipedia.org/wiki/Ruby_on_Rails
#http://en.wikipedia.org/wiki/Software_as_a_service
#http://en.wikipedia.org/wiki/Representational_state_transfer
#http://en.wikipedia.org/wiki/Embedded_Ruby

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-04T01:03:41Z

Nmanjun3:

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [http://en.wikipedia.org/wiki/Software_as_a_service SaaS] is one such video series made by University of California, Berkley.

=Introduction=

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

=MVC responsibilities=
In Rails, applications are broken into three types of components: models, views, and controllers.

* '''Model''': Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get and manipulate data. Different methods are provided by ''ActiveRecord'' to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

* '''Controller''': In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since ''params[:id]'' can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

* '''View''': Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in ''app/view/movies/show.html.erb''. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

=Adding a new controller action to Rails application=
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ''ActionController'' super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate ''app/controllers/*_controller.rb''. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in ''routes.rb''
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in ''app/views/model/action.html.erb''. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the ''app/view/model''. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in ''app/view/movie/index.html.erb''. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

=URI helpers=

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, ''movie_path(movie)'', ''edit_movie_path(movie)'', ''new_movie_path''. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies ''index.html.erb''. Somewhere on that page there will be a link whose argument is movie_path with an argument.

<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be ''movie/:id'' with a ''GET'' method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>

From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route ''GET /movies/:id'' which matches the show action of the movies controller. Further it takes '':id'' and stores as ''params[:id]''. With that ''params[:id]'', appropriate controller action is called.

[[File:Helper_methods.gif‎|700 px|thumb|center|Connecting URIs using helper methods]]

Further the user can return to the list of movies with the help of another URI helper, ''movies_path''. ''movies_path'' with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and ''movies_path'' is a method call.

=References=

#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#https://class.coursera.org/saas/lecture/preview/index
#http://en.wikipedia.org/wiki/Ruby_on_Rails
#http://en.wikipedia.org/wiki/Software_as_a_service
#http://en.wikipedia.org/wiki/Representational_state_transfer
#http://en.wikipedia.org/wiki/Embedded_Ruby

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-04T00:58:13Z

Nmanjun3:

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [http://en.wikipedia.org/wiki/Software_as_a_service SaaS] is one such video series made by University of California, Berkley.

=Introduction=

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

=MVC responsibilities=
In Rails, applications are broken into three types of components: models, views, and controllers.

* '''Model''': Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get and manipulate data. Different methods are provided by ''''ActiveRecord'''' to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

* '''Controller''': In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since ''''params[:id]'''' can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

* '''View''': Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in ''''app/view/movies/show.html.erb''''. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

=Adding a new controller action to Rails application=
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ''''ActionController'''' super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate ''''app/controllers/*_controller.rb''''. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in ''''routes.rb''''
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in ''''app/views/model/action.html.erb''''. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the ''''app/view/model''''. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in ''''app/view/movie/index.html.erb''''. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

=URI helpers=

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, ''''movie_path(movie)'''', ''''edit_movie_path(movie)'''', ''''new_movie_path''''. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies ''''index.html.erb''''. Somewhere on that page there will be a link whose argument is movie_path with an argument.

<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be ''''movie/:id'''' with a ''''GET'''' method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>

From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route ''''GET /movies/:id'''' which matches the show action of the movies controller. Further it takes :id and stores as params[:id]. With that params[:id], appropriate controller action is called.

[[File:Helper_methods.gif‎|700 px|thumb|center|Connecting URIs using helper methods]]

Further the user can return to the list of movies with the help of another URI helper, ''''movies_path''''. ''''movies_path'''' with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and ''''movies_path'''' is a method call.

=References=

#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#https://class.coursera.org/saas/lecture/preview/index
#http://en.wikipedia.org/wiki/Ruby_on_Rails
#http://en.wikipedia.org/wiki/Software_as_a_service
#http://en.wikipedia.org/wiki/Representational_state_transfer
#http://en.wikipedia.org/wiki/Embedded_Ruby

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-04T00:53:59Z

Nmanjun3: /* MVC responsibilities */

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [http://en.wikipedia.org/wiki/Software_as_a_service SaaS] is one such video series made by University of California, Berkley.

=Introduction=

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

=MVC responsibilities=
In Rails, applications are broken into three types of components: models, views, and controllers.

* '''Model''': Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get/manipulate data. Different methods are provided by ActiveRecord to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

* '''Controller''': In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since params[:id] can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

* '''View''': Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in app/view/movies/show.html.erb. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

=Adding a new controller action to Rails application=
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ActionController super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate app/controllers/*_controller.rb. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in routes.rb
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in app/views/model/action.html.erb. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the app/view/model. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in app/view/movie/index.html.erb. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

=URI helpers=

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, movie_path(movie),edit_movie_path(movie), new_movie_path. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies index.index.html.erb. Somewhere on that page there will be a link whose argument is movie_path with an argument.

<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be movie/:id with a GET method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>

From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route GET /movies/:id which matches the show action of the movies controller. Further it takes :id and stores as params[:id]. With that params[:id], appropriate controller action is called.

[[File:Helper_methods.gif‎|700 px|thumb|center|Connecting URIs using helper methods]]

Further the user can return to the list of movies with the help of another URI helper, movies_path. movies_path with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and movies_path is a method call.

=References=

#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#https://class.coursera.org/saas/lecture/preview/index
#http://en.wikipedia.org/wiki/Ruby_on_Rails
#http://en.wikipedia.org/wiki/Software_as_a_service
#http://en.wikipedia.org/wiki/Representational_state_transfer
#http://en.wikipedia.org/wiki/Embedded_Ruby

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-04T00:51:35Z

Nmanjun3:

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [http://en.wikipedia.org/wiki/Software_as_a_service SaaS] is one such video series made by University of California, Berkley.

=Introduction=

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

=MVC responsibilities=
In Rails, applications are broken into three types of components: models, views, and controllers.

* Model: Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get/manipulate data. Different methods are provided by ActiveRecord to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

*Controller: In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since params[:id] can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

*View: Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in app/view/movies/show.html.erb. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

=Adding a new controller action to Rails application=
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ActionController super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate app/controllers/*_controller.rb. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in routes.rb
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in app/views/model/action.html.erb. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the app/view/model. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in app/view/movie/index.html.erb. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

=URI helpers=

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, movie_path(movie),edit_movie_path(movie), new_movie_path. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies index.index.html.erb. Somewhere on that page there will be a link whose argument is movie_path with an argument.

<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be movie/:id with a GET method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>

From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route GET /movies/:id which matches the show action of the movies controller. Further it takes :id and stores as params[:id]. With that params[:id], appropriate controller action is called.

[[File:Helper_methods.gif‎|700 px|thumb|center|Connecting URIs using helper methods]]

Further the user can return to the list of movies with the help of another URI helper, movies_path. movies_path with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and movies_path is a method call.

=References=

#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#https://class.coursera.org/saas/lecture/preview/index
#http://en.wikipedia.org/wiki/Ruby_on_Rails
#http://en.wikipedia.org/wiki/Software_as_a_service
#http://en.wikipedia.org/wiki/Representational_state_transfer
#http://en.wikipedia.org/wiki/Embedded_Ruby

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-04T00:44:34Z

Nmanjun3:

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [https://class.coursera.org/saas/lecture/preview/index SaaS] is one such video series made by University of California, Berkley.

=Introduction=

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

=MVC responsibilities=
In Rails, applications are broken into three types of components: models, views, and controllers.

* Model: Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get/manipulate data. Different methods are provided by ActiveRecord to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

*Controller: In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since params[:id] can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

*View: Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in app/view/movies/show.html.erb. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

==Adding a new controller action to Rails application==
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ActionController super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate app/controllers/*_controller.rb. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in routes.rb
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in app/views/model/action.html.erb. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the app/view/model. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in app/view/movie/index.html.erb. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

==URI helpers==

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, movie_path(movie),edit_movie_path(movie), new_movie_path. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies index.index.html.erb. Somewhere on that page there will be a link whose argument is movie_path with an argument.

<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be movie/:id with a GET method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>

From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route GET /movies/:id which matches the show action of the movies controller. Further it takes :id and stores as params[:id]. With that params[:id], appropriate controller action is called.

[[File:Helper_methods.gif‎|700 px|thumb|center|Connecting URIs using helper methods]]

Further the user can return to the list of movies with the help of another URI helper, movies_path. movies_path with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and movies_path is a method call.

==References==

#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#http://guides.rubyonrails.org/

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-03T03:09:42Z

Nmanjun3: /* URI helpers */

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [https://class.coursera.org/saas/lecture/preview/index SaaS] is one such video series made by University of California, Berkley.

==Introduction==

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

==MVC responsibilities==
In Rails, applications are broken into three types of components: models, views, and controllers.

* Model: Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get/manipulate data. Different methods are provided by ActiveRecord to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

*Controller: In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since params[:id] can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

*View: Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in app/view/movies/show.html.erb. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

==Adding a new controller action to Rails application==
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ActionController super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate app/controllers/*_controller.rb. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in routes.rb
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in app/views/model/action.html.erb. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the app/view/model. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in app/view/movie/index.html.erb. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

==URI helpers==

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, movie_path(movie),edit_movie_path(movie), new_movie_path. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies index.index.html.erb. Somewhere on that page there will be a link whose argument is movie_path with an argument.

<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be movie/:id with a GET method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>

From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route GET /movies/:id which matches the show action of the movies controller. Further it takes :id and stores as params[:id]. With that params[:id], appropriate controller action is called.

[[File:Helper_methods.gif‎|700 px|thumb|center|Connecting URIs using helper methods]]

Further the user can return to the list of movies with the help of another URI helper, movies_path. movies_path with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and movies_path is a method call.

==References==

#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#http://guides.rubyonrails.org/

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-03T03:08:59Z

Nmanjun3: /* URI helpers */

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [https://class.coursera.org/saas/lecture/preview/index SaaS] is one such video series made by University of California, Berkley.

==Introduction==

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

==MVC responsibilities==
In Rails, applications are broken into three types of components: models, views, and controllers.

* Model: Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get/manipulate data. Different methods are provided by ActiveRecord to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

*Controller: In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since params[:id] can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

*View: Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in app/view/movies/show.html.erb. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

==Adding a new controller action to Rails application==
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ActionController super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate app/controllers/*_controller.rb. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in routes.rb
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in app/views/model/action.html.erb. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the app/view/model. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in app/view/movie/index.html.erb. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

==URI helpers==

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, movie_path(movie),edit_movie_path(movie), new_movie_path. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies index.index.html.erb. Somewhere on that page there will be a link whose argument is movie_path with an argument.

<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be movie/:id with a GET method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>

From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route GET /movies/:id which matches the show action of the movies controller. Further it takes :id and stores as params[:id]. With that params[:id], appropriate controller action is called.

[[File:Helper_methods.gif‎|700 px|thumb|Connecting URIs using helper methods]]

Further the user can return to the list of movies with the help of another URI helper, movies_path. movies_path with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and movies_path is a method call.

==References==

#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#http://guides.rubyonrails.org/

File:Helper methods.gif

2012-10-03T03:07:46Z

Nmanjun3: helper methods

helper methods

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-03T02:44:33Z

Nmanjun3: /* URI helpers */

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [https://class.coursera.org/saas/lecture/preview/index SaaS] is one such video series made by University of California, Berkley.

==Introduction==

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

==MVC responsibilities==
In Rails, applications are broken into three types of components: models, views, and controllers.

* Model: Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get/manipulate data. Different methods are provided by ActiveRecord to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

*Controller: In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since params[:id] can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

*View: Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in app/view/movies/show.html.erb. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

==Adding a new controller action to Rails application==
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ActionController super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate app/controllers/*_controller.rb. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in routes.rb
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in app/views/model/action.html.erb. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the app/view/model. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in app/view/movie/index.html.erb. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

==URI helpers==

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, movie_path(movie),edit_movie_path(movie), new_movie_path. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies index.index.html.erb. Somewhere on that page there will be a link whose argument is movie_path with an argument.
[[File:Helper_methods.png‎|700 px|thumb|right|Connecting URIs using helper methods]]
<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be movie/:id with a GET method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>

From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route GET /movies/:id which matches the show action of the movies controller. Further it takes :id and stores as params[:id]. With that params[:id], appropriate controller action is called.

Further the user can return to the list of movies with the help of another URI helper, movies_path. movies_path with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and movies_path is a method call.

==References==

#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#http://guides.rubyonrails.org/

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-03T02:42:43Z

Nmanjun3: /* URI helpers */

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [https://class.coursera.org/saas/lecture/preview/index SaaS] is one such video series made by University of California, Berkley.

==Introduction==

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

==MVC responsibilities==
In Rails, applications are broken into three types of components: models, views, and controllers.

* Model: Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get/manipulate data. Different methods are provided by ActiveRecord to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

*Controller: In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since params[:id] can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

*View: Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in app/view/movies/show.html.erb. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

==Adding a new controller action to Rails application==
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ActionController super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate app/controllers/*_controller.rb. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in routes.rb
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in app/views/model/action.html.erb. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the app/view/model. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in app/view/movie/index.html.erb. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

==URI helpers==

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, movie_path(movie),edit_movie_path(movie), new_movie_path. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

[[File:Helper_methods.png‎|700 px|thumb|right|Connecting URIs using helper methods]]
The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies index.index.html.erb. Somewhere on that page there will be a link whose argument is movie_path with an argument.
<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be movie/:id with a GET method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>

From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route GET /movies/:id which matches the show action of the movies controller. Further it takes :id and stores as params[:id]. With that params[:id], appropriate controller action is called.

Further the user can return to the list of movies with the help of another URI helper, movies_path. movies_path with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and movies_path is a method call.

==References==

#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#http://guides.rubyonrails.org/

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-03T02:41:35Z

Nmanjun3: /* URI helpers */

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [https://class.coursera.org/saas/lecture/preview/index SaaS] is one such video series made by University of California, Berkley.

==Introduction==

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

==MVC responsibilities==
In Rails, applications are broken into three types of components: models, views, and controllers.

* Model: Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get/manipulate data. Different methods are provided by ActiveRecord to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

*Controller: In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since params[:id] can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

*View: Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in app/view/movies/show.html.erb. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

==Adding a new controller action to Rails application==
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ActionController super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate app/controllers/*_controller.rb. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in routes.rb
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in app/views/model/action.html.erb. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the app/view/model. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in app/view/movie/index.html.erb. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

==URI helpers==

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, movie_path(movie),edit_movie_path(movie), new_movie_path. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies index.index.html.erb. Somewhere on that page there will be a link whose argument is movie_path with an argument.
<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be movie/:id with a GET method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>
[[File:Helper_methods.png‎|700 px|thumb|right|Connecting URIs using helper methods]]
From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route GET /movies/:id which matches the show action of the movies controller. Further it takes :id and stores as params[:id]. With that params[:id], appropriate controller action is called.

Further the user can return to the list of movies with the help of another URI helper, movies_path. movies_path with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and movies_path is a method call.

==References==

#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#http://guides.rubyonrails.org/

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-03T02:38:28Z

Nmanjun3: /* URI helpers */

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [https://class.coursera.org/saas/lecture/preview/index SaaS] is one such video series made by University of California, Berkley.

==Introduction==

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

==MVC responsibilities==
In Rails, applications are broken into three types of components: models, views, and controllers.

* Model: Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get/manipulate data. Different methods are provided by ActiveRecord to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

*Controller: In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since params[:id] can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

*View: Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in app/view/movies/show.html.erb. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

==Adding a new controller action to Rails application==
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ActionController super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate app/controllers/*_controller.rb. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in routes.rb
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in app/views/model/action.html.erb. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the app/view/model. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in app/view/movie/index.html.erb. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

==URI helpers==

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, movie_path(movie),edit_movie_path(movie), new_movie_path. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies index.index.html.erb. Somewhere on that page there will be a link whose argument is movie_path with an argument.
<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be movie/:id with a GET method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>
From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route GET /movies/:id which matches the show action of the movies controller. Further it takes :id and stores as params[:id]. With that params[:id], appropriate controller action is called.
[[File:Helper_methods.png‎|700 px|thumb|right|Connecting URIs using helper methods <ref name="https://www.youtube.com/watch?v=zy7P0E9gs-E" />]]

Further the user can return to the list of movies with the help of another URI helper, movies_path. movies_path with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and movies_path is a method call.

==References==

#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#http://guides.rubyonrails.org/

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-03T02:38:04Z

Nmanjun3: /* References */

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [https://class.coursera.org/saas/lecture/preview/index SaaS] is one such video series made by University of California, Berkley.

==Introduction==

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

==MVC responsibilities==
In Rails, applications are broken into three types of components: models, views, and controllers.

* Model: Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get/manipulate data. Different methods are provided by ActiveRecord to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

*Controller: In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since params[:id] can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

*View: Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in app/view/movies/show.html.erb. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

==Adding a new controller action to Rails application==
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ActionController super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate app/controllers/*_controller.rb. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in routes.rb
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in app/views/model/action.html.erb. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the app/view/model. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in app/view/movie/index.html.erb. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

==URI helpers==

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, movie_path(movie),edit_movie_path(movie), new_movie_path. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies index.index.html.erb. Somewhere on that page there will be a link whose argument is movie_path with an argument.
<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be movie/:id with a GET method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>
From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route GET /movies/:id which matches the show action of the movies controller. Further it takes :id and stores as params[:id]. With that params[:id], appropriate controller action is called.
[[File:Helper_methods.png‎|200 px|thumb|right|Connecting URIs using helper methods <ref name="https://www.youtube.com/watch?v=zy7P0E9gs-E" />]]

Further the user can return to the list of movies with the help of another URI helper, movies_path. movies_path with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and movies_path is a method call.

==References==

#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#http://guides.rubyonrails.org/

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-03T02:37:43Z

Nmanjun3: /* URI helpers */

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [https://class.coursera.org/saas/lecture/preview/index SaaS] is one such video series made by University of California, Berkley.

==Introduction==

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

==MVC responsibilities==
In Rails, applications are broken into three types of components: models, views, and controllers.

* Model: Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get/manipulate data. Different methods are provided by ActiveRecord to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

*Controller: In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since params[:id] can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

*View: Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in app/view/movies/show.html.erb. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

==Adding a new controller action to Rails application==
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ActionController super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate app/controllers/*_controller.rb. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in routes.rb
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in app/views/model/action.html.erb. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the app/view/model. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in app/view/movie/index.html.erb. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

==URI helpers==

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, movie_path(movie),edit_movie_path(movie), new_movie_path. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies index.index.html.erb. Somewhere on that page there will be a link whose argument is movie_path with an argument.
<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be movie/:id with a GET method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>
From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route GET /movies/:id which matches the show action of the movies controller. Further it takes :id and stores as params[:id]. With that params[:id], appropriate controller action is called.
[[File:Helper_methods.png‎|200 px|thumb|right|Connecting URIs using helper methods <ref name="https://www.youtube.com/watch?v=zy7P0E9gs-E" />]]

Further the user can return to the list of movies with the help of another URI helper, movies_path. movies_path with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and movies_path is a method call.

==References==
{{Infobox Algorithm
|class=[[Sorting algorithm]]
|image=[[File:Merge-sort-example-300px.gif]]
|caption=An example of merge sort. First divide the list into the smallest unit (1 element), then compare each element with the adjacent list to sort and merge the two adjacent lists. Finally all the elements are sorted and merged.
|data=[[Array data structure|Array]]
|time=O(''n'' log ''n'')
|best-time=O(''n'' log ''n'') typical,
O(''n'') natural variant
|average-time=O(''n'' log ''n'')
|space=O(''n'') auxiliary
|optimal=Yes
}}

#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#http://guides.rubyonrails.org/

File:Helper methods.png

2012-10-03T02:31:44Z

Nmanjun3: uploaded a new version of "File:Helper methods.png": Edit

Helper methods

File:Helper methods.png

2012-10-03T02:29:31Z

Nmanjun3: Helper methods

Helper methods

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-03T02:20:00Z

Nmanjun3: /* References */

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [https://class.coursera.org/saas/lecture/preview/index SaaS] is one such video series made by University of California, Berkley.

==Introduction==

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

==MVC responsibilities==
In Rails, applications are broken into three types of components: models, views, and controllers.

* Model: Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get/manipulate data. Different methods are provided by ActiveRecord to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

*Controller: In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since params[:id] can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

*View: Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in app/view/movies/show.html.erb. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

==Adding a new controller action to Rails application==
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ActionController super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate app/controllers/*_controller.rb. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in routes.rb
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in app/views/model/action.html.erb. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the app/view/model. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in app/view/movie/index.html.erb. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

==URI helpers==

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, movie_path(movie),edit_movie_path(movie), new_movie_path. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies index.index.html.erb. Somewhere on that page there will be a link whose argument is movie_path with an argument.
<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be movie/:id with a GET method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>
From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route GET /movies/:id which matches the show action of the movies controller. Further it takes :id and stores as params[:id]. With that params[:id], appropriate controller action is called.

Further the user can return to the list of movies with the help of another URI helper, movies_path. movies_path with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and movies_path is a method call.

==References==
{{Infobox Algorithm
|class=[[Sorting algorithm]]
|image=[[File:Merge-sort-example-300px.gif]]
|caption=An example of merge sort. First divide the list into the smallest unit (1 element), then compare each element with the adjacent list to sort and merge the two adjacent lists. Finally all the elements are sorted and merged.
|data=[[Array data structure|Array]]
|time=O(''n'' log ''n'')
|best-time=O(''n'' log ''n'') typical,
O(''n'') natural variant
|average-time=O(''n'' log ''n'')
|space=O(''n'') auxiliary
|optimal=Yes
}}

#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#http://guides.rubyonrails.org/

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-03T02:13:43Z

Nmanjun3: /* References */

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [https://class.coursera.org/saas/lecture/preview/index SaaS] is one such video series made by University of California, Berkley.

==Introduction==

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

==MVC responsibilities==
In Rails, applications are broken into three types of components: models, views, and controllers.

* Model: Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get/manipulate data. Different methods are provided by ActiveRecord to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

*Controller: In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since params[:id] can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

*View: Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in app/view/movies/show.html.erb. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

==Adding a new controller action to Rails application==
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ActionController super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate app/controllers/*_controller.rb. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in routes.rb
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in app/views/model/action.html.erb. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the app/view/model. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in app/view/movie/index.html.erb. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

==URI helpers==

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, movie_path(movie),edit_movie_path(movie), new_movie_path. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies index.index.html.erb. Somewhere on that page there will be a link whose argument is movie_path with an argument.
<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be movie/:id with a GET method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>
From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route GET /movies/:id which matches the show action of the movies controller. Further it takes :id and stores as params[:id]. With that params[:id], appropriate controller action is called.

Further the user can return to the list of movies with the help of another URI helper, movies_path. movies_path with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and movies_path is a method call.

==References==
{{Infobox Algorithm
|class=[[Sorting algorithm]]
|image=[[File:Merge-sort-example-300px.gif]]
|caption=An example of merge sort. First divide the list into the smallest unit (1 element), then compare each element with the adjacent list to sort and merge the two adjacent lists. Finally all the elements are sorted and merged.
|data=[[Array data structure|Array]]
|time=O(''n'' log ''n'')
|best-time=O(''n'' log ''n'') typical,
O(''n'') natural variant
|average-time=O(''n'' log ''n'')
|space=O(''n'') auxiliary
|optimal=Yes
}}

[[File:Example.jpg]]
[[File:Example.jpg]]
#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#http://guides.rubyonrails.org/

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-03T02:13:07Z

Nmanjun3: /* References */

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [https://class.coursera.org/saas/lecture/preview/index SaaS] is one such video series made by University of California, Berkley.

==Introduction==

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

==MVC responsibilities==
In Rails, applications are broken into three types of components: models, views, and controllers.

* Model: Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get/manipulate data. Different methods are provided by ActiveRecord to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

*Controller: In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since params[:id] can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

*View: Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in app/view/movies/show.html.erb. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

==Adding a new controller action to Rails application==
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ActionController super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate app/controllers/*_controller.rb. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in routes.rb
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in app/views/model/action.html.erb. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the app/view/model. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in app/view/movie/index.html.erb. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

==URI helpers==

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, movie_path(movie),edit_movie_path(movie), new_movie_path. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies index.index.html.erb. Somewhere on that page there will be a link whose argument is movie_path with an argument.
<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be movie/:id with a GET method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>
From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route GET /movies/:id which matches the show action of the movies controller. Further it takes :id and stores as params[:id]. With that params[:id], appropriate controller action is called.

Further the user can return to the list of movies with the help of another URI helper, movies_path. movies_path with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and movies_path is a method call.

==References==
{{Infobox Algorithm
|class=[[Sorting algorithm]]
|image=[[File:Merge-sort-example-300px.gif]]
|caption=An example of merge sort. First divide the list into the smallest unit (1 element), then compare each element with the adjacent list to sort and merge the two adjacent lists. Finally all the elements are sorted and merged.
|data=[[Array data structure|Array]]
|time=O(''n'' log ''n'')
|best-time=O(''n'' log ''n'') typical,
O(''n'') natural variant
|average-time=O(''n'' log ''n'')
|space=O(''n'') auxiliary
|optimal=Yes
}}

[[File:Ruby.jpg]]

#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#http://guides.rubyonrails.org/

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-03T02:05:15Z

Nmanjun3: /* URI helpers */

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [https://class.coursera.org/saas/lecture/preview/index SaaS] is one such video series made by University of California, Berkley.

==Introduction==

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

==MVC responsibilities==
In Rails, applications are broken into three types of components: models, views, and controllers.

* Model: Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get/manipulate data. Different methods are provided by ActiveRecord to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

*Controller: In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since params[:id] can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

*View: Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in app/view/movies/show.html.erb. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

==Adding a new controller action to Rails application==
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ActionController super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate app/controllers/*_controller.rb. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in routes.rb
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in app/views/model/action.html.erb. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the app/view/model. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in app/view/movie/index.html.erb. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

==URI helpers==

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, movie_path(movie),edit_movie_path(movie), new_movie_path. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies index.index.html.erb. Somewhere on that page there will be a link whose argument is movie_path with an argument.
<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be movie/:id with a GET method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>
From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route GET /movies/:id which matches the show action of the movies controller. Further it takes :id and stores as params[:id]. With that params[:id], appropriate controller action is called.

Further the user can return to the list of movies with the help of another URI helper, movies_path. movies_path with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and movies_path is a method call.

==References==
{{Infobox Algorithm
|class=[[Sorting algorithm]]
|image=[[File:Merge-sort-example-300px.gif]]
|caption=An example of merge sort. First divide the list into the smallest unit (1 element), then compare each element with the adjacent list to sort and merge the two adjacent lists. Finally all the elements are sorted and merged.
|data=[[Array data structure|Array]]
|time=O(''n'' log ''n'')
|best-time=O(''n'' log ''n'') typical,
O(''n'') natural variant
|average-time=O(''n'' log ''n'')
|space=O(''n'') auxiliary
|optimal=Yes
}}

#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#http://guides.rubyonrails.org/

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-03T02:02:46Z

Nmanjun3: /* References */

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [https://class.coursera.org/saas/lecture/preview/index SaaS] is one such video series made by University of California, Berkley.

==Introduction==

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

==MVC responsibilities==
In Rails, applications are broken into three types of components: models, views, and controllers.

* Model: Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get/manipulate data. Different methods are provided by ActiveRecord to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

*Controller: In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since params[:id] can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

*View: Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in app/view/movies/show.html.erb. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

==Adding a new controller action to Rails application==
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ActionController super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate app/controllers/*_controller.rb. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in routes.rb
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in app/views/model/action.html.erb. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the app/view/model. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in app/view/movie/index.html.erb. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

==URI helpers==

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, movie_path(movie),edit_movie_path(movie), new_movie_path. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies index.index.html.erb. Somewhere on that page there will be a link whose argument is movie_path with an argument.
<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be movie/:id with a GET method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>
From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route GET /movies/:id which matches the show action of the movies controller. Further it takes :id and stores as params[:id]. With that params[:id], appropriate controller action is called. </br>

Further the user can return to the list of movies with the help of another URI helper, movies_path. movies_path with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and movies_path is a method call.

==References==
{{Infobox Algorithm
|class=[[Sorting algorithm]]
|image=[[File:Merge-sort-example-300px.gif]]
|caption=An example of merge sort. First divide the list into the smallest unit (1 element), then compare each element with the adjacent list to sort and merge the two adjacent lists. Finally all the elements are sorted and merged.
|data=[[Array data structure|Array]]
|time=O(''n'' log ''n'')
|best-time=O(''n'' log ''n'') typical,
O(''n'') natural variant
|average-time=O(''n'' log ''n'')
|space=O(''n'') auxiliary
|optimal=Yes
}}

#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#http://guides.rubyonrails.org/

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-03T02:00:15Z

Nmanjun3:

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [https://class.coursera.org/saas/lecture/preview/index SaaS] is one such video series made by University of California, Berkley.

==Introduction==

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

==MVC responsibilities==
In Rails, applications are broken into three types of components: models, views, and controllers.

* Model: Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get/manipulate data. Different methods are provided by ActiveRecord to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

*Controller: In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since params[:id] can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

*View: Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in app/view/movies/show.html.erb. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

==Adding a new controller action to Rails application==
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ActionController super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate app/controllers/*_controller.rb. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in routes.rb
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in app/views/model/action.html.erb. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the app/view/model. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in app/view/movie/index.html.erb. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

==URI helpers==

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another. In the above mentioned example of a view, there are three helper methods used namely, movie_path(movie),edit_movie_path(movie), new_movie_path. More examples are shown below in the table.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

The following example illustrates how the helper methods work. Lets consider that the user is looking at the list of all movies index.index.html.erb. Somewhere on that page there will be a link whose argument is movie_path with an argument.
<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that sets up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be movie/:id with a GET method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>
From here, once the URI is hit, the controller looks up for this URI in the routing subsystem. This corresponds to the Restful route GET /movies/:id which matches the show action of the movies controller. Further it takes :id and stores as params[:id]. With that params[:id], appropriate controller action is called. </br>

Further the user can return to the list of movies with the help of another URI helper, movies_path. movies_path with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Here Back to List is the text that is click-able and movies_path is a method call.

==References==
#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#http://guides.rubyonrails.org/

CSC/ECE 517 Fall 2012/ch1b 1w64 nn

2012-10-03T01:40:39Z

Nmanjun3: /* Adding a new controller action to Rails application */

<big>''' SaaS - 3.12 Controller and views'''</big><br>

[https://class.coursera.org/saas/lecture/preview/index Coursera] is a technology company that provides free online education by making videos. [https://class.coursera.org/saas/lecture/preview/index SaaS] is one such video series made by University of California, Berkley.

==Introduction==

This article focuses on the concepts and usage of controllers and views in [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] application which is available as one of the [https://www.youtube.com/watch?v=zy7P0E9gs-E SaaS video] lectures. It covers the general information on model, view and controllers in a Rails application.

==MVC responsibilities==
In Rails, applications are broken into three types of components: models, views, and controllers.

* Model: Application's state is maintained by models. It not only stores the state of the application in databases but also imposes business rules on that data. It contains methods to get/manipulate data. Different methods are provided by ActiveRecord to do that. An example is shown below.

<pre>
class Movie < ActiveRecord::Base
belongs_to :genre
has_many :actor

def find_movie_name(movie_id)
if movie_id then
movie = Movie.find_by_id(movie_id)
return movie.name
end
end
</pre>

*Controller: In [http://en.wikipedia.org/wiki/Representational_state_transfer REST] applications, the controller acts as a middle man to synchronize the communication between model and view. It is responsible for receiving request from the user, getting data from the model and making it available to the view for displaying data to the user. Controllers are also responsible for routing the requests to internal actions. This is facilitated by helper methods. An example is shown below.

<pre>
class MoviesController < ApplicationController
def show
@movie = Movie.find(params[:id])
end
end
</pre>

Here params is the parameter from the request that is parsed out by the routing subsystem. This contains the id of the movie that the user wants to find which can be fetched by calling movie.find. In a real application this is unsafe and must be handled by an exception since params[:id] can happen to be a non-existing value and will result in an error. Finally the instance variable @movie in the controller is going to be available to the view.

*View: Views are responsible for creating response in the browser to display data and allow user interaction. In the above example Show is going to display the details of a movie (genre, actors). To select the view for the rendering step, the default action the rails will take is, to find a view whose directory name matches the name of its class which is movies and finally matches the name of that particular action i.e show. Thus the view for the above action can be found in app/view/movies/show.html.erb. Here ERb ( [http://en.wikipedia.org/wiki/Embedded_Ruby Embedded Ruby]) is used to generate dynamic content in Rails application.

==Adding a new controller action to Rails application==
In Rails controller forms the logical center of the application. Controller is essentially a Ruby class is inherited from ActionController super class. To create a controller, these steps must be followed.
* Add the action method in the appropriate app/controllers/*_controller.rb. This method will have the actual code to do whatever the action is meant to do. For example,
<pre>
class MoviesController < ApplicationController
def new
end
end
</pre>
Here the new function creates an instance of Movies controller.
* Create a route in config/routes.rb. When the application receives a request from the user, it is this route that determines the appropriate controller and action to run. Example of a route in routes.rb
<pre>
match 'movies/new' => 'movies#new'
</pre>
* Ensure there is something for the action to render in app/views/model/action.html.erb. Every trip through the controller has to end with returning something to the view. Even if there is no explicit render at the end of controller, by default, Rails looks for that particular action in the app/view/model. For example, the controller shown below has an index method as follows:
<pre>
class MoviesController < ApplicationController
def index
@movies = Movie.all
end
end
</pre>
The view for this controller will be found in app/view/movie/index.html.erb. It is shown below as follows:
<pre>
<h1>Listing Movies</h1>

<table>
<tr>
<th>Title</th>
<th>Description</th>
<th></th>
<th></th>
<th></th>
</tr>

<% @movies.each do |movie| %>
<tr>
<td><%= movie.title %></td>
<td><%= movie.description %></td>
<td><%= link_to 'Show', movie_path(movie) %></td>
<td><%= link_to 'Edit', edit_movie_path(movie) %></td>
<td><%= link_to 'Remove', movie, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>

<br />

<%= link_to 'New movie', new_movie_path %>
</pre>

==URI helpers==

The routing subsystem that maps the URI to different controller actions also provides helper methods that generates routes in the context of that page. These routes generated by helper classes is used by the user in the views to navigate from one page to another.

{| class="wikitable"
|-
! Helper method !! URI returned !! RESTful route !! Action
|-
| movies_path || /movies || GET /movies || index
|-
| movies_path || /movies || POST /movies || create
|-
| new_movie_path || /movies/new || GET /movies/new || new
|-
| edit_movie_path(m) || /movies/1/edit || GET /movies/:id/edit || edit
|-
| movie_path(m) || /movies/1 || GET /movies/:id || show
|-
| movie_path(m) || /movies/1 || PUT /movies/:id || update
|-
| movie_path(m) || /movies/1 || DELETE /movies/:id || destroy
|}

Just like the routing subsystem allows us to map http methods and URI's to different control actions, the same routing subsystem also sets up these helpful methods that will generate the routes in the context of the page. Example when we are looking at the list of all movies index.index.html.haml, somewhere on that page there will be a link whose argument is movie_path with an argument.
<pre>
link_to movie_path(3)
</pre>
movie_path is the helper that set up and gives back a route to the show action for that movie id. So when the user clicks on it, the URI that is going to be generated is going to be movie/:id with a GET method because its a link. This is how it looks in the actual html.
<pre>
<a href="/movies/3">...</a>
</pre>
From here, once the URI is hit, that is going to get looked up in the routing subsystem. /movies/something matches the show action of the movies controller and it will take the wild card thing :id and puts that in params[:id]
<pre>
GET /movies/:id
{:action=>"show", :controller=>"movies"}
params[:id]
</pre>
With that appropriate controller action is called
<pre>
def show
@movie = Movie.find(params[:id])
end
</pre>
Here the controller action can reasonably expect to find that params[:id] will be whatever this route said that it should match.
We can let the user return a list of all movies. We can use RESTful URI helpers. Here it is the index action. movies_path with no arguments links to the index action. The line to add on show template is
<pre>
link_to 'Back to List', movies_path
</pre>
Back to List is the text that is click-able and movies_path is a method call.
As the app gets more complicate, these mechanism scale very nicely

==References==
#https://www.youtube.com/watch?v=zy7P0E9gs-E
#http://guides.rubyonrails.org/
#http://guides.rubyonrails.org/