Transcript Rails
Rails
21-Mar-17
What is Rails?
Rails is a framework for building web applications
This involves:
Getting information from the user (client), using HTML forms
Doing validation
Maintaining session information
Managing a database
Displaying results to the user
Rails differs from similar frameworks in C++ or Java
Rails applications can be built much more quickly
Rails requires knowledge of fewer technologies
Required software
You need:
The Ruby language
A database, such as MySQL
A Ruby-capable web server, such as lightppd, WEBRick, or Mongrel
On Windows, InstantRails provides all of these
On Macintosh, Locomotive provides these
On Linux you probably have to assemble the pieces yourself
It’s also helpful to have:
A good text editor, such as TextMate or TextPad
A Ruby IDE, such as Eclipse with the RDT plugin, or RadRails
A GUI interface for looking at your database
Rails philosophy
Convention over configuration
Don't Repeat Yourself (DRY)
Other frameworks use several XML configuration files to specify where
everything is, and how the parts are related
Rails assumes a standard configuration.
Every piece of information (program or data) should be represented once
and only once
Rails provides a structure that encourages DRY
Agile development
In Rails we start with a working program and “grow” it by making small
changes
In Rails it is easy to re-test after every small change
Rails provides strong support for unit testing
Three environments
By default, Rails projects use three environments
The development environment
The test environment
Classes are reloaded after every change, so every change you make
happens “immediately”--you don’t have to restart the server
This is where you do most of your work
Classes are also reloaded after every change
For each test, Rails creates a fresh copy of the data in the test database
The production environment
Classes are only loaded once
Changes typically require stopping and restarting the server
The environment is tuned for speed
Scripts
A lot of work is done in the Rails world by generate
and rake scripts
The generate scripts are called like this:
ruby script\generate generator options args
Generators typically create files and directories for you
Some built-in generators are: controller, model, scaffold,
mailer, and web_service
The rake (like UNIX make) scripts are called like this:
rake name:name:name
Rake scripts are typically used to propagate changes by
updating files that depend on other files
Rake scripts are written in Ruby
Starting an application
To create a new application, say, “MyApplication”,
enter the command:
rails MyApplication
This creates a directory (folder) named MyApplication
and, beneath it, a large directory structure and a
number of files
Creating an empty database
The following instructions are for MySQL on
Windows, as configured in InstantRails
1. At the command line, enter
mysql -u root –p
and just hit Enter when prompted for a password
2. Type the following lines into MySQL:
•
create database MyApp_development;
grant all on MyApp_development.* to 'ODBC'@'localhost';
The above creates the development database for an application
named MyApp; you can repeat these two lines to create the test and
production databases, if you like
3. Type exit
The directories, I
Rails creates the following subdirectories of the
MyApplication directory:
app/ -- more about this directory later
components/ -- reusable components
config/ -- configuration information, including database
connection parameters
db/ -- database schema information
doc/ -- autogenerated documentation
lib/ -- code produced by your company and shared by many
applications
vendor/ -- purchased code shared by many applications
The directories, II
More subdirectories
log/ -- log files produced by the application
public/ -- the web-accessible directory; your program
appears to be running from here
Rakefile/ -- scripts for creating documentation and tests
script/ -- utility scripts
tests/ -- unit tests, functional tests, mocks, and fixtures
Of these, the app subdirectory is the most important,
but you will probably also use the config, db, and test
directories
The app subdirectory
The app/ subdirectory contains
The controllers/ subdirectory, which contains
The helpers/ subdirectory, which contains
The application_helper.rb file
A table_helper.rb file for each table in your application
The models/ subdirectory, which contains
The application.rb file
A table_controller.rb file for each table in your application
A table.rb file for each table in your application
The views/ subdirectory, which contains
The index.rhtml file
action.rhtml files for most of the methods in your controllers
Naming conventions in Ruby
Ruby requires the following naming conventions:
Ruby encourages the following naming conventions:
The names of classes, modules, and constants must begin
with a capital letter
The names of variables and methods must begin with a
lowercase letter
The names of classes, modules, and constants should be
written in CamelCase; for example, ActiveRecord
The names of variables and methods should be written in all
lowercase, with underscores between words; for example,
chunky_bacon
File names in Ruby follow the same rules as variable
and function names; for example, my_application.rb
“Convention over configuration”
In other web application frameworks, you need many
configuration files to specify how the various parts of
your application fit together
Rails assumes you have named things in a certain way,
then finds the parts and fits them together itself
Rails uses both capitalization and pluralization rules
Model-View-Controller (MVC)
Rails uses the MVC design pattern
In somewhat oversimplified terms,
The Model does all the “business logic,” or computation
The View displays results to the user
The Controller ties it all together
It gets input from the user
It takes actions depending on what the user wants done; this
typically involves asking the Model to do some work, then
collecting the results of that work
It tells the View to display those results
Naming conventions in Rails, I
The Model:
The tables have lowercased, underscored, pluralized names
A class that describes a record in a table has a CamelCase singular name
A file containing the class has a lowercased, underscored, singular name
The View:
The URL is lowercased, underscored, and singular, and has the form
http://...app/controller/method/parameters
The file is lowercased, underscored, and singular, and has the form
app/views/controller/method.rhtml
The layout files in app/views/layout follow the same file naming
conventions
The helper module is CamelCase and singular
The helper file is lowercased, underscored, and singular, and named
app/helpers/application_helper.rb
Naming conventions in Rails, II
The Controller:
The URL is lowercased, underscored, and singular, and has
the form http://...app/controller/method/parameters
The controller class is CamelCase and singular
The file is lowercased, underscored, and singular, and has the
form app/controllers/table_controller.rhtml
The controller’s methods are lowercased and underscored,
and should typically be verbs
This sounds like a lot of conventions to learn, but in
reality Rails creates most of these for you
Typical flow of control
A request from the browser goes to a controller in
app/controllers/
The controller talks to the model in app/models/
(initially, by means of a scaffold)
The model sends requests to the database (in db/)
The database returns information to the model
The model manipulates the information and returns it to
the controller
The controller uses a .rhtml template in app/views/
to send a response to the browser
Scaffolding
You can use “scaffolds” to build models and controllers for
your application
A scaffold is an initial set of files which you will modify to do the
work of your application
The script
ruby script\generate scaffold model controller
will create the files app/models/model.rb and
app/controllers/controller_controller.rb, among others
scaffold adds these methods: index, list, show, destroy,
new, create, edit, update
To learn more about scaffold, see
ActionController::Scaffolding::ClassMethods
The browser call
The user talks to the application from a browser
A request from the browser goes to a method in a
controller
Make the browser request with
http://host:port/ClassName/method/parameters
If method is omitted, the default is index
method must be defined in class_name_controller.rb
The parameters are often blank
The controller
A request from the browser goes to a method in a controller
Create the controller with
ruby script/generate controller ClassName
(use \ instead of / on Windows)
The controller will be app/controllers/class_name_controller.rb
The controller extends ActionController::Base
Parameters sent to the URL (for example, by appending ?key=value pairs),
are available by calling the params method
If xyz is a key, its value can be accessed with either params['xyz'] or
params[:xyz]
A controller method must end by either:
Passing control to another controller method, with
redirect_to :action => "some_other_method", or
Passing control to a view template, either
Explicitly by ending with render :action => "some_template", or
Implicitly, by not specifying a render action; this will render the template with the
same name as the method
The model
If you are going to use a database (most Rails
applications do), create the database first
Create the model with
ruby script/generate model ClassName
The model extends ActiveRecord::Base
The easiest things to add to the model are validations
Validations check whether a requested database entry or
update is valid
A number of validation methods are defined in
ActiveRecord::Validations::Base
Some useful validations
validates_presence_of(*attr_names)
Tests that the attributes are not blank
validates_numericality_of(*attr_names)
Tests that the values of the attributes are numeric
validates_length_of(attr_name, restrictions)
Tests that the attribute's value satisfies the size restrictions.
Some restrictions are: :minimum=>number, :maximum=>number,
:is=>number, :within=>range
validates_uniqueness_of(*attr_names)
Tests that the attribute values are unique
validates_inclusion_of(attr_name, :in=>enumerable_object)
Tests that the attribute's value is in the enumeration
validates_each(*attrs) {|record, attr, value| ...}
Tests each attribute with the code in the block
The view(s)
Views are written as HTML templates, in files with the
.rhtml extension
The RHTML file uses ERb, embedded Ruby:
Ruby statements (code to be executed, but not included in the
HTML page) are enclosed in <%
%>
Ruby values, to be included in the resultant HTML, are
enclosed in <%= %>
Some available methods are: start_form_tag,
submit_tag, render, link_to, and end_form_tag
Components of a view
A view may consist of three kinds of parts: the main
view, a layout, and some partials
Layout
Main view
Partial
Constructing a view
Here’s what happens when you browse to
http://localhost:3000/application/noun/verb
Rails calls the verb method in
controllers/noun_controller.rb.
1. When the controller's verb method finishes, Rails looks for a template
named views/noun/verb.rhtml
2. Next, Rails looks for a template “layout” file named
views/layouts/noun.rhtml
•
If it can't find this file, it looks for a layout file named
views/layouts/application.rhtml.
3. If no layout file is found, Rails uses the views/noun/verb.rhtml
template “as is”
4. If a layout file is found, Rails inserts the verb.rhtml into the layout file,
in the location marked <%= yield %>, and uses this combination to
return to the user
5. Partials in the verb.rhtml file, indicated by
<%= render :partial => 'form' %> , are filled in
Methods useful in the view
params
Returns a list of parameters, as given to the controller
render(:action => partial)
Renders the given partial template within the current template
link_to(name, options = { }, html_options = nil)
Returns the HTML for an <href> link.
name is the text to be displayed.
options are a hash of values to be used in creating the URL.
html_options are a hash of key/value pairs to be added to the <href> tag
One useful Rails-specific pair is :confirm => ' question?'
h(string)
Replaces &, ", <, and > with &, ", <, and >, respectively. (This is a Ruby,
not Rails, method.)
form_tag, submit_tag, text_area_tag, radio_button_tag, etc.
Rails methods for creating HTML tags (but you can write the tags directly).
stylesheet_link_tag(name)
Causes the HTML to use the stylesheet in public/stylesheets/name.css
Where methods come from
Controllers extend ActionController::Base
Models extend ActiveRecord::Base
All the relevant methods should be documented somewhere in
http://api.rubyonrails.com/
Modules (mixins) make this more complicated, because a class
can “mix in” methods from a variety of modules
Bad: The documentation isn’t complete (where is the params method?)
Bad: The documentation doesn’t say what version it’s for
Good: The source code is immediately available
For example, validates_numericality_of is in module
ActiveRecord::Validations::ClassMethods
Yes, Rails is easy, but only after you learn your way around in it
Adding tables to the database
Rails cannot create a database; that has to be done in
SQL
You can create a file (say, create.sql) containing SQL
commands to create some tables, then execute
mysql MyApp_development <create.sql
MySQL commands were given earlier in this talk
This executes the SQL commands in the
MyApp_development database, which is (presumably)
the development database for an application named MyApp
However, you can (mostly) avoid SQL and write the
database directly in Ruby, by using migrations
Starting migrations
To fully connect Rails to the database takes four steps
1. To translate the database into Ruby code, move to the application directory and
enter
rake db:schema:dump
this creates a file schema.rb in the db directory
2. Generate the migration file db/001_baseline_schema.rb by executing the
line
ruby script\generate migration BaselineSchema
3. To tell Rails that this is the first version of the database, edit the schema.rb
file and change the line
ActiveRecord::Schema.define() do
to
ActiveRecord::Schema.define(:version => 1) do
4. Finally, enter the command
rake db:migrate
This creates a schema_info table in the database to tell SQL that this is the first
version
Modifying the database
To make changes to the database, first run the script
ruby script\generate migration SomeMeaningfulName
This creates a file named xxx_some_meaningful_name.rb, where xxx
is the next version number
The file will look like this:
class SomeMeaningfulName < ActiveRecord::Migration
def self.up
end
def self.down
end
end
Edit this file to make the changes
The up method should make the changes, the down method should undo
them
To “migrate” these changes to the actual database, run the script
rake db:migrate
Methods to use in up and down
add_column(table_name, column_name, type, options = { })
Adds a new column to the named table
remove_column(table_name, column_name)
Removes a column from the database
rename_column(table, column, new_column_name)
The type may be :primary_key, :string, :text, :integer, :float, :decimal,
:datetime, :timestamp, :time, :date, :binary, or :boolean
The options may include :limit, :default, :null, :precision, or :scale
Renames a column
Other changes are most easily made by removing a column and
adding it again with a different type or options
Status
This talk is based on a paper I’m writing, A Concise
Guide to Rails, at
http://alliance.seas.upenn.edu/~cis700/ruby/conciserails.html
I’m still learning my way around Rails myself
I may have some things wrong
I know I’m missing some important things
I would very much like to hear your corrections and
suggestions
A small amount of extra credit is available
The End