CSC/ECE 517 Fall 2012/ch2b 1w61 ns: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
(Created page with "Connecting Architectural Concepts to Rails Apps The structure of a typical Rake file is as follows: app /models/, views/, controllers/ /helpers /assets/s...")
 
No edit summary
Line 1: Line 1:
Connecting Architectural Concepts to Rails Apps
==Connecting Architectural Concepts to Rails Apps==


The structure of a typical Rake file is as follows:
The structure of a typical Rake file is as follows:
Line 19: Line 19:
Tasks are the main unit of work in a Rakefile. Tasks have a name (usually given as a symbol or a string), a list of prerequisites (more symbols or strings) and a list of actions (given as a block).
Tasks are the main unit of work in a Rakefile. Tasks have a name (usually given as a symbol or a string), a list of prerequisites (more symbols or strings) and a list of actions (given as a block).
Rails is a web application development framework written in the Ruby language. It is designed to make programming web applications easier by making assumptions about what every developer needs to get started. It allows you to write less code while accomplishing more than many other languages and frameworks.
Rails is a web application development framework written in the Ruby language. It is designed to make programming web applications easier by making assumptions about what every developer needs to get started. It allows you to write less code while accomplishing more than many other languages and frameworks.
==Tier System==
Each entity has a model, controller and a set of views.
The css style sheets are used to style the html view of the application.
Routes.rb maps the URI’s and methods to things that happen in the controller.
The routes play a crucial role in communication between the Presentation tier and the logic tier.
The persistence tier consists of three different types of databases that are used during the course of development and testing of the application.
All the activities carried out in setting up and testing the application are logged for future reference and easier debugging.
==Rails as an MVC Framework==
Our Application consists of:
Controllers – which effectively make use of the routing subsystem
Models – which are linked to the persistence tier i.e the database and store the data in the relational database tables
Controllers are needed to make views to be rendered which turn .haml to .html which is the view markup
Models are sub classes of ActiveRecord::Base which is an object relational mapping layer (ORM layer)that is useful in connecting to the database
Views are subclasses of ActionView consisting of reusable code that is used to manipulate views
Controllers are subclasses of ApplicationController which provide common functionality which can be used accordingly in the user application
==Rails Philosophies==
The Rails philosophy includes several guiding principles:
• DRY – “Don’t Repeat Yourself” – suggests that writing the same code over and over again is a bad thing.
• Convention Over Configuration – means that Rails makes assumptions about what you want to do and how you’re going to do it, rather than requiring you to specify every little thing through endless configuration files.
• REST is the best pattern for web applications – organizing your application around resources and standard HTTP verbs is the fastest way to go.
==References==
http://docs.rubyrake.org/user_guide/chapter03.html
http://rake.rubyforge.org/files/doc/rakefile_rdoc.html
http://guides.rubyonrails.org/getting_started.html

Revision as of 02:04, 19 November 2012

Connecting Architectural Concepts to Rails Apps

The structure of a typical Rake file is as follows:

app /models/, views/, controllers/

        /helpers
        /assets/stylesheets/application.css

config /routes.rb

       /database.yml

db /development.sqlite3,test.sqlite3

       /migrate/

log /development.log, test.log

There is no special format for a Rakefile. A Rakefile contains executable Ruby code. Anything legal in a ruby script is allowed in a Rakefile. There is no special syntax in a Rakefile, there are some conventions that are used in a Rakefile that are a little unusual in a typical Ruby program. Since a Rakefile is tailored to specifying tasks and actions, the idioms used in a Rakefile are designed to support that. Tasks are the main unit of work in a Rakefile. Tasks have a name (usually given as a symbol or a string), a list of prerequisites (more symbols or strings) and a list of actions (given as a block). Rails is a web application development framework written in the Ruby language. It is designed to make programming web applications easier by making assumptions about what every developer needs to get started. It allows you to write less code while accomplishing more than many other languages and frameworks.

Tier System

Each entity has a model, controller and a set of views. The css style sheets are used to style the html view of the application. Routes.rb maps the URI’s and methods to things that happen in the controller. The routes play a crucial role in communication between the Presentation tier and the logic tier. The persistence tier consists of three different types of databases that are used during the course of development and testing of the application. All the activities carried out in setting up and testing the application are logged for future reference and easier debugging.

Rails as an MVC Framework

Our Application consists of: Controllers – which effectively make use of the routing subsystem Models – which are linked to the persistence tier i.e the database and store the data in the relational database tables Controllers are needed to make views to be rendered which turn .haml to .html which is the view markup Models are sub classes of ActiveRecord::Base which is an object relational mapping layer (ORM layer)that is useful in connecting to the database Views are subclasses of ActionView consisting of reusable code that is used to manipulate views Controllers are subclasses of ApplicationController which provide common functionality which can be used accordingly in the user application

Rails Philosophies

The Rails philosophy includes several guiding principles: • DRY – “Don’t Repeat Yourself” – suggests that writing the same code over and over again is a bad thing. • Convention Over Configuration – means that Rails makes assumptions about what you want to do and how you’re going to do it, rather than requiring you to specify every little thing through endless configuration files. • REST is the best pattern for web applications – organizing your application around resources and standard HTTP verbs is the fastest way to go.


References

http://docs.rubyrake.org/user_guide/chapter03.html http://rake.rubyforge.org/files/doc/rakefile_rdoc.html http://guides.rubyonrails.org/getting_started.html