24-Jun-15 Rails

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 Other frameworks use several XML configuration files to specify where everything is, and how the parts are related Rails assumes a standard configuration. Don't Repeat Yourself (DRY) 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 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 The test environment 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 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 application.rb file A table _controller.rb file for each table in your application 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 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: 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 Ruby encourages the following naming conventions: 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 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 controller / method / parameters 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 a pp/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 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 Main view LayoutPartial

Constructing a view Here’s what happens when you browse to 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, and uses this combination to return to the user 5.Partials in the verb.rhtml file, indicated by ' 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 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 tag One useful Rails-specific pair is :confirm => ' question? ' h( string ) Replaces &, ", with &, &quot ;, <, 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 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 Modules (mixins) make this more complicated, because a class can “mix in” methods from a variety of modules 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 MySQL commands were given earlier in this talk You can create a file (say, create.sql ) containing SQL commands to create some tables, then execute mysql MyApp_development <create.sql 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 The type may be :primary_key, :string, :text, :integer, :float, :decimal, :datetim e, :timestamp, :time, :date, :binary, or :boolean The options may include :limit, :default, :null, :precision, or :scale remove_column( table_name, column_name ) Removes a column from the database rename_column( table, column, new_column_name ) 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 rails.html rails.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