• A SQL table is a lot like a spreadsheet. You have rows and columns. You should have a table for each data model.
• Tables and their columns need to manually created and removed. When you need to make a new column, you need to manually tell the system that it needs to be created.
• “Primary” column(s) are unique and define it. Generally speaking this is just an id number. Rails sets it up so that the database will auto increment the id so you don’t have to worry.

So let’s setup our database. We’ll be using Postgres, so we need to install it. For Macs, use Postgres.app. It’s simple and easy. Postgres provides an installer for Windows. And Linux can use your favorite package manager.

And once it’s setup, we need a database (set of tables) to put it into. You can use the included GUI or the command “createdb” to create a database.

Then we need to install the pg gem, which might be a small issue on any machine. For example on Mac you may need to run env ARCHFLAGS="-arch x86_64" gem install pg -- --with-pg-config=/Applications/Postgres.app/Contents/MacOS/bin/pg_config to give it the right config file to build the C extension against. Googling eventually finds the right answer.

Hopefully now you have the gem installed, and we can run bundler with pg and ActiveRecord:

ruby '2.1.0'
source 'https://rubygems.org'
gem 'rack', '~>1.5.2'
gem 'actionpack', '~> 4.1.0.beta1'
gem 'actionview', '~> 4.1.0.beta1'
gem 'railties', '~> 4.1.0.beta1'
gem 'activerecord', '~> 4.1.0.beta1'
gem 'pg'

And the Railtie:

require File.expand_path('../boot', __FILE__)

require 'rails'
require 'action_controller/railtie'
require 'action_view/railtie'
require 'active_record/railtie'

Bundler.require

module GenericCMS
  class Application < Rails::Application
    # you could put some custom stuff here if you wanted

    config.secret_key_base = "rails really wants this to be defined"
  end
end

Now we need to setup the postgres password. Create a new file, config/database.yml, to put the postgres password that you used to setup the postgres root password:

# SQLite version 3.x
#   gem install sqlite3
#
#   Ensure the SQLite 3 gem is defined in your Gemfile
#   gem 'sqlite3'
development:
  adapter: postgresql
  encoding: utf8
  reconnect: false
  database: NAMEOFDATABASE
  pool: 5
  username: USERNAME
  password: PASSWORD
  host: localhost

Don’t forget to change the pertinent parts.

With this we can create our first migration to get the database to have the right table information. So let’s create that file:

class CreatePages < ActiveRecord::Migration
  def change
    create_table :pages do |t|
      t.string :name
      t.string :handle
      t.text :body_text

      t.timestamps
    end
  end
end

So that’s a mouthful that’s easier explained in the Rails guide. In short this creates a table with the listed columns. By default the id primary column is create for you, as well as an automatic “created_at” and “updated_at” columns too.

To run our migration you need to run bundle exec rake db:migrate. This occurs whenever you need to run any database migrations.

And now let’s update our Page model:

class Page < ActiveRecord::Base
  validates_presence_of :name
  validates_length_of :name, minimum: 3
end

Yep, it is that small. Rails is smart enough to know that the attributes is the name of the columns. It also includes a finder method and handles saving to the database for you. Of course we need to create the “create page” page since we have an empty database:

class PagesController < ApplicationController
  def new
    @page = Page.new
    render :action=>:edit
  end

  def create
    @page = Page.new
    @page.name = params['page']['name']
    @page.handle = params['page']['handle']
    @page.body_text = params['page']['body_text']
    if @page.save
      redirect_to @page
    else
      render :action=>:edit
    end
  end

  def show
    @page = Page.find(params[:id])
  end

  def edit
    @page = Page.find(params[:id])
  end

  def update
    @page = Page.find(params[:id])
    @page.name = params['page']['name']
    @page.handle = params['page']['handle']
    @page.body_text = params['page']['body_text']
    if @page.save
      redirect_to @page
    else
      render :action=>:edit
    end
  end
end

Notice how we don’t even need to create a new form? It can re-use the same form because it knows that the data is a new entry instead of an old entry and redirects accordingly.

Lastly, there’s associations, which you can read on the Rails guide. We’ll be going into associations when we start the main project, but for now the guide will do.

And that gets you up to speed with all the major parts of Rails. There’s still tons more to learn, but there’s better guides for what you need after this point:

• How to query the database to get certain items or groupings
• How to send email
• All about the asset pipeline that takes care of CSS and Javascript files for you

And that’s it. This last part is available on Github.

[{"id":1,"name":"Page","body_text":"<p>This is a page.</p>","handle":"page-1"},{"id":1,"name":"Page 2","body_text":"<p>This is another page.</p>","handle":"page-2"}]

To work with this data, we’re going to create a special class called “Page” to handle our pages. Generally speaking, any class that exclusively deals with data is called a “model”. Thus, our new file is going to be put in app/models/page.rb:

class Page

# class methods

  class << self
    def where(predecate)
      raise ArgumentError.new("predecate must be a hash!") unless predecate.is_a?(Hash)
      load_data

      # this isn't the best way to do this (maybe via inject), but to show for example
      # for all the data rows
      found_data = @data.select do |row|
        has_all_conditions = true
        # check to see if the row supports all our conditions by using the AND statement
        predecate.each do |key, value|
          has_all_conditions = has_all_conditions && row[key.to_s] == value
        end
        # if it has all conditions, then this is true
        has_all_conditions
      end
      found_data.map{|x| Page.new(x)}
    end

    private

    def load_data
      return true if @loaded
      rawdata = File.read(File.join(Rails.root,'db','pages.json'))
      @data = JSON::load(rawdata)
    end
  end


# instance methods

  def initialize(data)
    @data = data
  end

  def id
    @data['id']
  end

  def name
    @data['name']
  end

  def body_text
    @data['body_text']
  end

  def handle
    @data['handle']
  end

end

This is a bunch of code to drop, but all it really does is load a JSON file and allows you to search for data.

And let’s modify our controller and view to use the new page data:

class MainpageController < ApplicationController
  def index
  end

  def show
    @page = Page.where(handle:params[:id]).first

    if @page.blank?
      render text: "<h1>404 Not Found</h1>", status: 404
    end

    #implicit render
  end
end

<h1><%= @page.name %></h1>
<%# Be very, very careful when using html_safe! %>
<%= @page.body_text.html_safe %>

If you just browse to “/page/page-2”, it will show the data for that page. Now that’s nice, but we can make it better.

Let’s start adding some Rails methods to the Page class to start adding some magic. We’re going to start with ActiveModel, which contains a bit of magic without requiring much more. So first let’s add it to our Gemfile:

ruby '2.1.0'
source 'https://rubygems.org'
gem 'rack', '~>1.5.2'
gem 'actionpack', '~> 4.1.0.beta1'
gem 'actionview', '~> 4.1.0.beta1'
gem 'railties', '~> 4.1.0.beta1'
gem 'activemodel', '~> 4.1.0.beta1'

And add it to our list of railties to preload it:

require File.expand_path('../boot', __FILE__)

require 'rails'
require 'action_controller/railtie'
require 'action_view/railtie'
require 'active_model/railtie'

Bundler.require

module GenericCMS
  class Application < Rails::Application
    # you could put some custom stuff here if you wanted

    config.secret_key_base = "rails really wants this to be defined"
  end
end

And so now we can add some specialized functions. First is ActiveModel::Model which adds some internal specialized functions:

• ActiveModel::Naming – which creates string names from your class names. Very useful for generating routes (and table names later on).
• ActiveModel::Translation – which automatically creates human names from the attribute name, and allows you to translate them to other languages if the translation file is available.
• ActiveModel::Conversion – which adds a few helper functions for routing
• ActiveModel::Validations – which we’ll get into a little bit later
• And a few internal methods like automatically creating the initialize function for us.

So let’s add it:

class Page

  include ActiveModel::Model
  attr_accessor :id, :name, :body_text, :handle

# class methods

  class << self
    def where(predecate)
      raise ArgumentError.new("predecate must be a hash!") unless predecate.is_a?(Hash)
      load_data

      # this isn't the best way to do this (maybe via inject), but to show for example
      # for all the data rows
      found_data = @data.select do |row|
        has_all_conditions = true
        # check to see if the row supports all our conditions by using the AND statement
        predecate.each do |key, value|
          has_all_conditions = has_all_conditions && row[key.to_s] == value
        end
        # if it has all conditions, then this is true
        has_all_conditions
      end
      found_data.map{|x| Page.new(x)}
    end

    private

    def load_data
      return true if @loaded
      rawdata = File.read(File.join(Rails.root,'db','pages.json'))
      @data = JSON::load(rawdata)
    end
  end


# instance methods

end

That’s already better, but we have no way of saving. So let’s add that:

class Page

  include ActiveModel::Model
  attr_accessor :id, :name, :body_text, :handle

# class methods

  class << self
    def where(predecate)
      raise ArgumentError.new("predecate must be a hash!") unless predecate.is_a?(Hash)
      load_data

      # this isn't the best way to do this (maybe via inject), but to show for example
      # for all the data rows
      found_data = @data.select do |row|
        has_all_conditions = true
        # check to see if the row supports all our conditions by using the AND statement
        predecate.each do |key, value|
          has_all_conditions = has_all_conditions && row[key.to_s] == value
        end
        # if it has all conditions, then this is true
        has_all_conditions
      end
      found_data.map{|x| Page.new(x)}
    end

    private

    def load_data
      return true if @loaded
      rawdata = File.read(File.join(Rails.root,'db','pages.json'))
      @data = JSON::load(rawdata)
    end
  end


# instance methods

  def attributes
    {
      'id'        => @id,
      'name'      => @name,
      'body_text' => @body_text,
      'handle'    => @handle
    }
  end

  def save
    # get the raw data
    rawstring = File.read(File.join(Rails.root,'db','pages.json'))
    rawdata = JSON::load(rawstring)
    # delete this record's row
    rawdata.delete_if {|row| row['id'] == @id }
    # add the new record to the raw data
    rawdata << attributes
    # save the raw data back to the file
    f = File.open(File.join(Rails.root,'db','pages.json'),'w')
    f.write rawdata.to_json
    f.close
    # return true so that we know it was successful
    true
  end

  def persisted?
    # this is always persisted with our flat files
    true
  end
end

Admittingly, not the most optimized flat-file format but we’ll figure that out later. Now that we can edit data and have added the ActiveModel::Conversion (via Model), we can now use resources on the routes. This is just an automatic route creator that does a bunch of magic for us.

Rails.application.routes.draw do
  get '/' => 'mainpage#index'
  resources :pages
end

Try a bundle exec rake routes to see what our routes looks like:

Prefix Verb   URI Pattern               Controller#Action
          GET    /                         mainpage#index
    pages GET    /pages(.:format)          pages#index
          POST   /pages(.:format)          pages#create
 new_page GET    /pages/new(.:format)      pages#new
edit_page GET    /pages/:id/edit(.:format) pages#edit
     page GET    /pages/:id(.:format)      pages#show
          PATCH  /pages/:id(.:format)      pages#update
          PUT    /pages/:id(.:format)      pages#update
          DELETE /pages/:id(.:format)      pages#destroy

So this creates a bunch of really common routes for us. Let’s use them. First we need a new class method called “find” that lets us find by a direct id number:

class Page

  include ActiveModel::Model
  attr_accessor :id, :name, :body_text, :handle

# class methods

  class << self
    def find(id)
      load_data
      detected = @data.detect{|row| row['id'].to_s == id.to_s}
      raise "Not Found!" if detected.blank?
      Page.new(detected)
    end

    def where(predecate)
...

And create a new controller:

class PagesController < ApplicationController
  def edit
    @page = Page.find(params[:id])
  end
end

And our edit page:

<h1>Editing <%= @page.name %></h1>
<%= form_for @page do |f| %>
  <%= f.label :name %>
  <%= f.text_field :name %>
  <br/>
  <%= f.label :handle %>
  <%= f.text_field :handle %>
  <br/>
  <%= f.label :body_text %>
  <%= f.text_area :body_text,:rows=>10,:cols=>50 %>
  <br/>
  <%= f.submit %>
<% end %>

This takes advantage of an ActionView form builder which automatically creates the form based on attributes and fills in the default value if it exists, and routes to the correct page if the resource routing exists.

Of course we need to create the update and show functions too:

class PagesController < ApplicationController
  def show
    @page = Page.find(params[:id])
  end

  def edit
    @page = Page.find(params[:id])
  end

  def update
    @page = Page.find(params[:id])
    @page.name = params['page']['name']
    @page.handle = params['page']['handle']
    @page.body_text = params['page']['body_text']
    if @page.save
      redirect_to @page
    else
      render :action=>:edit
    end
  end
end

Here we simply see the page attributes getting updated. Now that we have the ability to edit pages, lets throw some magic in the monkey works. First, callbacks:

class Page

  include ActiveModel::Model
  extend ActiveModel::Callbacks
  attr_accessor :id, :name, :body_text, :handle, :updated_at

  define_model_callbacks :save

  before_save :touch

# class methods

  class << self
    def find(id)
      load_data
      detected = @data.detect{|row| row['id'].to_s == id.to_s}
      raise "Not Found!" if detected.blank?
      Page.new(detected)
    end

    def where(predecate)
      raise ArgumentError.new("predecate must be a hash!") unless predecate.is_a?(Hash)
      load_data

      # this isn't the best way to do this (maybe via inject), but to show for example
      # for all the data rows
      found_data = @data.select do |row|
        has_all_conditions = true
        # check to see if the row supports all our conditions by using the AND statement
        predecate.each do |key, value|
          has_all_conditions = has_all_conditions && row[key.to_s] == value
        end
        # if it has all conditions, then this is true
        has_all_conditions
      end
      found_data.map{|x| Page.new(x)}
    end

    private

    def load_data
      return true if @loaded
      rawdata = File.read(File.join(Rails.root,'db','pages.json'))
      @data = JSON::load(rawdata)
    end
  end


# instance methods

  def attributes
    {
      'id'        => @id,
      'name'      => @name,
      'body_text' => @body_text,
      'handle'    => @handle,
      'updated_at'=> @updated_at
    }
  end

  def save
    run_callbacks :save do
      # get the raw data
      rawstring = File.read(File.join(Rails.root,'db','pages.json'))
      rawdata = JSON::load(rawstring)
      # delete this record's row
      rawdata.delete_if {|row| row['id'] == @id }
      # add the new record to the raw data
      rawdata << attributes
      # save the raw data back to the file
      f = File.open(File.join(Rails.root,'db','pages.json'),'w')
      f.write rawdata.to_json
      f.close
      # return true so that we know it was successful
      true
    end
  end

  def touch
    @updated_at = Time.now
  end

  def persisted?
    # this is always persisted with our flat files
    true
  end
end

You should be familiar with callbacks, and this is the same. You can define (or have defined for you), various callbacks. For instance, this touches a new “updated_at” attribute which might be useful.

Another useful module is ActiveModel::Validation which allows one to check to see if the data validations certain conditions. For example, you may want a name or title or not be blank and have a certain minimum. For example you could do this:

class Page

  include ActiveModel::Model
  extend ActiveModel::Callbacks
  attr_accessor :id, :name, :body_text, :handle, :updated_at

  define_model_callbacks :save

  before_save :touch

  validate :name_minimum_size

# class methods

  class << self
    def find(id)
      load_data
      detected = @data.detect{|row| row['id'].to_s == id.to_s}
      raise "Not Found!" if detected.blank?
      Page.new(detected)
    end

    def where(predecate)
      raise ArgumentError.new("predecate must be a hash!") unless predecate.is_a?(Hash)
      load_data

      # this isn't the best way to do this (maybe via inject), but to show for example
      # for all the data rows
      found_data = @data.select do |row|
        has_all_conditions = true
        # check to see if the row supports all our conditions by using the AND statement
        predecate.each do |key, value|
          has_all_conditions = has_all_conditions && row[key.to_s] == value
        end
        # if it has all conditions, then this is true
        has_all_conditions
      end
      found_data.map{|x| Page.new(x)}
    end

    private

    def load_data
      return true if @loaded
      rawdata = File.read(File.join(Rails.root,'db','pages.json'))
      @data = JSON::load(rawdata)
    end
  end


# instance methods

  def attributes
    {
      'id'        => @id,
      'name'      => @name,
      'body_text' => @body_text,
      'handle'    => @handle,
      'updated_at'=> @updated_at
    }
  end

  def save
    return false if !valid?
    run_callbacks :save do
      # get the raw data
      rawstring = File.read(File.join(Rails.root,'db','pages.json'))
      rawdata = JSON::load(rawstring)
      # delete this record's row
      rawdata.delete_if {|row| row['id'] == @id }
      # add the new record to the raw data
      rawdata << attributes
      # save the raw data back to the file
      f = File.open(File.join(Rails.root,'db','pages.json'),'w')
      f.write rawdata.to_json
      f.close
      # return true so that we know it was successful
      true
    end
  end

  def touch
    @updated_at = Time.now
  end

  def name_minimum_size
    if @name.nil?
      errors.add(:name, 'Must exist.')
    elsif @name.length < 3
      errors.add(:name, 'Must have at least three characters.')
    end
  end

  def persisted?
    # this is always persisted with our flat files
    true
  end
end

But there are built-in validators for common validations:

class Page

  include ActiveModel::Model
  extend ActiveModel::Callbacks
  attr_accessor :id, :name, :body_text, :handle, :updated_at

  define_model_callbacks :save

  before_save :touch

  validates_presence_of :name
  validates_length_of :name, minimum: 3
...

The rest of the validators are on the Rails guide.

That’s the basics of attributes and how it can modify your saving. Now let’s focus on databases.

As always, code examples are on Github.

]]> http://rofish.net/2014/01/ruby-for-programmers-part-15-action-packed-viewing/ Mon, 20 Jan 2014 10:45:22 +0000 http://rofish.net/?p=149 Continue reading →]]> So as I mentioned in the last part of rendered, we built a fairly simple rendering engine using Rails’ built-in templating engine ERB. And that’s fine, but there’s still a lot of code in our controllers and Rails has a full featured rendering system called ActionView, which not only includes the rendering methods but tons of helpers to build pre-filled forms, etc.

So first let’s add ActionView to our Gemfile:

ruby '2.1.0'
source 'https://rubygems.org'
gem 'rack', '~>1.5.2'
gem 'actionpack', '~> 4.1.0.beta1'
gem 'actionview', '~> 4.1.0.beta1'
gem 'railties', '~> 4.1.0.beta1'

And after a bundle install, ActionView is available. It also adds the “erubis” gem, which is better, safer, and faster ERB handling than the simple built-in ERB handler.

We’re also going to add the railtie to our application.rb just so that ActionView has access to the various Rails configuration files:

require File.expand_path('../boot', __FILE__)

require 'rails'
require 'action_controller/railtie'
require 'action_view/railtie'

Bundler.require

module GenericCMS
  class Application < Rails::Application
    # you could put some custom stuff here if you wanted

    config.secret_key_base = "rails really wants this to be defined"
  end
end

And lastly, add the renderer to our controller:

class MainpageController < ActionController::Metal
  include AbstractController::Rendering
  
  include ActionController::UrlFor
  include Rails.application.routes.url_helpers #required to tell UrlFor which routes to use
  include ActionController::Redirecting
  include ActionView::Rendering
  include ActionController::Rendering
  include ActionController::ImplicitRender

  include AbstractController::Callbacks
  include ActionController::Rescue
  include ActionController::Instrumentation

  before_filter :doing_stuff
  rescue_from ZeroDivisionError, with: :divided_by_zero

  prepend_view_path(File.join(Rails.root,'app','views'))

  def doing_stuff
    @hi = 'sup'
  end

  def index
  end

  def show
    if params[:id] == "1"
      # do nothing, thus implicit render
    else
      render text: "<h1>404 Not Found</h1>", status: 404
    end
  end

  def divided_by_zero
    self.response_body = "<h1>You divided by zero. This is not allowed as you may break all of physics."
  end
end

In a Metal, you need to define where the views are location, such the line in #18. But notice that we got rid of all that rendering code. And our pages now render!

Going over all the different helpers would take far too long, so I’m just going to mention them as I get into them. The Guide on Form Helpers is a better resource. However, there is a couple of big notes to add:

First, HTML safety. Nasty insertable HTML and Javascript to steal your cookies and delete your pages is everywhere, so we don’t want to trust anything from the database. So every String that passes through ActionView is sanitized unless it’s marked as safe. So for example, if we change our @hi variable to @hi = '


sup

', then what gets outputted in our index is: Front Page! <h1>sup</h1> It actually will convert so that it displays the HTML. This is a safety first option, but if for some reason you can trust the output, then you can use #.html_safe in the ERB to mark as safe:

<h1>Front Page! <%= @hi.html_safe %></h1>

This marks it as safe to straight output vs. sanitizing.

And secondly, layouts! Should be obviously useful as any webpage has the same headers and footers, so let’s render the inside from the outside. To enable, just change to ActionView::Layouts:

class MainpageController < ActionController::Metal
  include AbstractController::Rendering
  
  include ActionController::UrlFor
  include Rails.application.routes.url_helpers #required to tell UrlFor which routes to use
  include ActionController::Redirecting
  include ActionView::Layouts
  include ActionController::Rendering
  include ActionController::ImplicitRender
...

And you’re good to go. While you can use the ActionController#layout method to define custom layouts, by default it uses the name of the controller to use as a layout. (If a layout doesn’t exist, then it will just render straight pages.) You put layouts in the app/views/layouts folder, separate from the controller views.

So let’s make a really simple layout:

<!DOCTYPE html>
<html>
<head>
<title>GenericCMS</title>
</head>
<body>
<h1>GenericCMS!</h1>
<p><a href="/">Index page</a></p>
<p><a href="/page/1">Page page</a></p>
<%= yield %>
</body>
</html>

And that’s it! With the magic filename, you have included a layout. Note that for layouts to render their insides, you must include a yield, which returns the inside of the layout.

Just to finalize things up, we’re going to set the controller to ActionController::Base now:

class MainpageController < ActionController::Base
  before_filter :doing_stuff
  rescue_from ZeroDivisionError, with: :divided_by_zero

  def doing_stuff
    @hi = '<h1>sup</h1>'
  end

  def index
  end

  def show
    if params[:id] == "1"
      # do nothing, thus implicit render
    else
      render text: "<h1>404 Not Found</h1>", status: 404
    end
  end

  def divided_by_zero
    self.response_body = "<h1>You divided by zero. This is not allowed as you may break all of physics."
  end
end

ActionController::Base is nothing but the Metal, but with all the batteries included. So it includes ALL the modules (and more!) that we’ve mentioned, preloads the view paths, and all that good stuff.

And just as a small detail, most Rails apps don’t have their controllers from the Base, but include an ApplicationController and use a hierarchical format:

class ApplicationController < ActionController::Base
  before_filter :doing_stuff
  rescue_from ZeroDivisionError, with: :divided_by_zero

  def doing_stuff
    @hi = '<h1>sup</h1>'
  end

  def divided_by_zero
    self.response_body = "<h1>You divided by zero. This is not allowed as you may break all of physics."
  end
end

class MainpageController < ApplicationController
  def index
  end
...

Because of hierarchy, this allows the filters to act for all inherited controllers, and is typically a good idea to have all controllers inherit from this.

And that’s ActionController. We have now built a very, very fancy method of generating webpages, but there’s no meat here. We’ll be going over the basics of the form generation soon, but to do that, we need something to save against, so we’ll be working next on persistence.

If you want to get ahead in the next few lessons, read up on the basics of SQL commands. (We’ll eventually be using Postgres for this project.) However, unlike HTML where you need to know the basic tags and such, you technically don’t need to know anything about SQL since Rails/ActiveRecord completely abstracts it out. However, it’s good to know that the abstraction is just a fancy SQL generator, so knowing why it works gets a leg up.

As always, working code is available here: https://github.com/ROFISH/ruby_for_programmers/tree/master/15

]]> http://rofish.net/2014/01/ruby-for-programmers-part-14-erb-my-html/ Mon, 20 Jan 2014 05:38:31 +0000 http://rofish.net/?p=146 Continue reading →]]> And now for something completely different.

Let’s say you want to generate some HTML. Using interpolated strings is generally not a good idea as it can lead to unmaintainable code. The best way to handle this is through a templating engine, which is output text intermixed with code. Thankfully, Ruby itself contains it’s own built-in templating engine: ERB

require 'erb'

x = 42
template = ERB.new <<-EOF
  The value of x is: <%= x %>
EOF
p template.result(binding)

=>  The value of x is: 42

‘binding’ is a special variable that is an object that contains the current variable scope. Yes, even scopes are objects that you can pass around. (Not recommended outside of template engines, as it messes with the garbage collector and may lead to memory leaks.)

There are three different tags to invoke:

<% Ruby code -- inline with output %>
<%= Ruby expression -- replace with result %>
<%# comment -- ignored -- useful in testing %>

The first allows one to write code before, and around, text. The second puts the result of code in the the output itself. The last is a way to write a comment. (You do write comments don’t you?)

So let’s add erb to our controller:

class MainpageController < ActionController::Metal
  include AbstractController::Callbacks
  include ActionController::Instrumentation
  include ActionController::Rescue
  include ActionController::UrlFor
  include Rails.application.routes.url_helpers #required to tell UrlFor which routes to use
  include ActionController::Redirecting

  before_filter :doing_stuff
  rescue_from ZeroDivisionError, with: :divided_by_zero

  def doing_stuff
    @hi = 'sup'
  end

  def index
    template = ERB.new <<-EOF
<h1>Front Page!</h1>
EOF
    self.response_body = template.result(binding)
  end

  def show
    template = ERB.new <<-EOF
<pre><%= params.to_yaml %> <%= params[:id] %></pre>
EOF
    self.response_body = template.result(binding)
  end

  def divided_by_zero
    self.response_body = "<h1>You divided by zero. This is not allowed as you may break all of physics."
  end
end

But that doesn’t really abstract that out enough to be useful. However, we can now put the text into different files, which is even better! We’re going to put the views into app/views/CONTROLLERNAME/ACTIONNAME.html.erb :

<h1>Front Page! <%= @hi %></h1>

<pre><%= params.to_yaml %> <%= params[:id] %></pre>

class MainpageController < ActionController::Metal
  include AbstractController::Callbacks
  include ActionController::Instrumentation
  include ActionController::Rescue
  include ActionController::UrlFor
  include Rails.application.routes.url_helpers #required to tell UrlFor which routes to use
  include ActionController::Redirecting

  before_filter :doing_stuff
  rescue_from ZeroDivisionError, with: :divided_by_zero

  def doing_stuff
    @hi = 'sup'
  end

  def index
    template = ERB.new File.read(File.join(Rails.root,'app','views','mainpage','index.html.erb'))
    self.response_body = template.result(binding)
  end

  def show
    template = ERB.new File.read(File.join(Rails.root,'app','views','mainpage','show.html.erb'))
    self.response_body = template.result(binding)
  end

  def divided_by_zero
    self.response_body = "<h1>You divided by zero. This is not allowed as you may break all of physics."
  end
end

So as you can see in the controller, we’re pretty much doing the same thing, which means abstraction time and another new module: ActionController::ImplicitRender, which simply calls #render after the method is run:

class MainpageController < ActionController::Metal
  include ActionController::Rescue
  include ActionController::UrlFor
  include Rails.application.routes.url_helpers #required to tell UrlFor which routes to use
  include ActionController::Redirecting
  include ActionController::ImplicitRender

  include AbstractController::Callbacks
  include ActionController::Instrumentation

  before_filter :doing_stuff
  rescue_from ZeroDivisionError, with: :divided_by_zero

  def doing_stuff
    @hi = 'sup'
  end

  def index
  end

  def show
  end

  def divided_by_zero
    self.response_body = "<h1>You divided by zero. This is not allowed as you may break all of physics."
  end

  def render(*args)
    template = ERB.new File.read(File.join(Rails.root,'app','views',params[:controller].to_s,"#{params[:action]}.html.erb"))
    self.response_body = template.result(binding)
  end
end

And let’s add some more programmability with that:

class MainpageController < ActionController::Metal
  include AbstractController::Rendering
  
  include ActionController::UrlFor
  include Rails.application.routes.url_helpers #required to tell UrlFor which routes to use
  include ActionController::Redirecting
  include ActionController::Rendering
  include ActionController::ImplicitRender

  include AbstractController::Callbacks
  include ActionController::Rescue
  include ActionController::Instrumentation

  before_filter :doing_stuff
  rescue_from ZeroDivisionError, with: :divided_by_zero

  def doing_stuff
    @hi = 'sup'
  end

  def index
  end

  def show
    if params[:id] == "1"
      # do nothing, thus implicit render
    else
      render text: "<h1>404 Not Found</h1>", status: 404
    end
  end

  def divided_by_zero
    self.response_body = "<h1>You divided by zero. This is not allowed as you may break all of physics."
  end

  def render_to_body(*args)
    if args.is_a?(Array) && args.first.is_a?(Hash)
      options = args.first
    else
      options = {}
    end

    _process_options(options)

    if options[:text]
      options[:text]
    else
      template = ERB.new File.read(File.join(Rails.root,'app','views',params[:controller].to_s,"#{params[:action]}.html.erb"))
      template.result(binding)
    end
  end

  def rendered_format
    Mime::HTML
  end
end

This lets us pass some options and force a different type of render if we so please. In this case, it lets us give a specialized 404 error if the page id isn’t what we expect. You can render a text value and a status. But what if we wanted to render a different layout? Well all that, and more, is in the ActionView, a culmination of all the rendering points and more, in the next part.

As usual, working code examples are in my Github: https://github.com/ROFISH/ruby_for_programmers/tree/master/14

]]> http://rofish.net/2014/01/ruby-for-programmers-meta-1-html/ Mon, 13 Jan 2014 10:09:38 +0000 http://rofish.net/?p=144 Continue reading →]]> Just in case you’re following from the blog, the next few parts will involve HTML rendering. Since these lessons are about Ruby / Rails, I’m going to assume that you know how to write HTML by hand, since we’ll be introducing a lot of magic functions that create HTML for you. If you don’t know how to HTML, Shay Howe wrote a wonderful HTML tutorial, which is available on his website.

Shay’s tutorial goes into box models and typography early on, which is important for creating custom pages. But, I will be using Bootstrap as the default CSS theme for this tutorial. So instead of writing my own box models and typography CSS, I’ll be using Bootstrap’s CSS and HTML prescriptions.

]]> http://rofish.net/2014/01/ruby-for-programmers-part-13-revving-some-metal/ Mon, 13 Jan 2014 09:30:31 +0000 http://rofish.net/?p=139 Continue reading →]]> Earlier we had put together a basic controller and used the Routing and Metal to render some basic pages, but since we’re going to build a simple Generic Content Manager out of this, the parameters seem important. The method in which we got that information was out of a weird quirk of information that was automatically included in the env variable that was passed around. However, there’s better ways to get this.

This isn’t a module but just automatically included in Metal that I forgot in the last part. The params variable holds all the parameters that was sent to the page, including the GET parameters, POST parameters, and parameters set by the routing:

class MainpageController < ActionController::Metal
  include AbstractController::Callbacks
  include ActionController::Instrumentation

  before_filter :doing_stuff

  def doing_stuff
    @hi = 'sup'
  end

  def index
    self.response_body = "<h1>Front Page #{@hi}</h1>"
  end

  def show
    self.response_body = "<pre>#{params.to_yaml} #{params[:id]} #{Rails.logger.to_yaml}</pre>"
  end
end

We’re also going to add Instrumentation to the controller too. This adds tons more useful logging like page benchmarks and displays all the parameters. We also need to make a small change to our application.rb file too:

require File.expand_path('../boot', __FILE__)

require 'rails'
require 'action_controller/railtie'

Bundler.require

module GenericCMS
  class Application < Rails::Application
    # you could put some custom stuff here if you wanted

    config.secret_key_base = "rails really wants this to be defined"
  end
end

This adds the ActionController ‘railtie’, which adds useful information to the class like where the Rails log is, ability to have a config information in the config/environments folder, and the like. Don’t forget to restart your app, and you’ll notice more logging information on each page load. Cool:

Started GET "/page/asdasgs" for 127.0.0.1 at 2014-01-13 01:12:21 -0700
Processing by MainpageController#show as HTML
  Parameters: {"id"=>"asdasgs"}
Completed 200 OK in 1ms

What page and how long it took and what parameters, all useful information.

Rescue lets you create custom rescuables in case something goes wrong:

class MainpageController < ActionController::Metal
  include AbstractController::Callbacks
  include ActionController::Instrumentation
  include ActionController::Rescue

  before_filter :doing_stuff
  rescue_from ZeroDivisionError, with: :divided_by_zero

  def doing_stuff
    @hi = 'sup'
  end

  def index
    self.response_body = "<h1>Front Page #{@hi}</h1>"
  end

  def show
    1/0
    self.response_body = "<pre>#{params.to_yaml} #{params[:id]} #{Rails.logger.to_yaml}</pre>"
  end

  def divided_by_zero
    self.response_body = "<h1>You divided by zero. This is not allowed as you may break all of physics."
  end
end

Pretty simple, this detects a Ruby Exception (or a subclass of Exception) and lets you render a special page from a specially defined method. In this basic example, I divided by zero accidentally in my code and rescued from that error. I should note that this is controller-wide, mostly as a last-ditch failsafe to render a decent 500 or 404 error to a user rather than the built-in HTML files.

class MainpageController < ActionController::Metal
  include AbstractController::Callbacks
  include ActionController::Instrumentation
  include ActionController::Rescue
  include ActionController::UrlFor
  include Rails.application.routes.url_helpers #required to tell UrlFor which routes to use
  include ActionController::Redirecting

  before_filter :doing_stuff
  rescue_from ZeroDivisionError, with: :divided_by_zero

  def doing_stuff
    @hi = 'sup'
  end

  def index
    #redirect_to "/show/butts"
    redirect_to :action=>:show, :id=>"butts"
  end

  def show
    self.response_body = "<pre>#{params.to_yaml} #{params[:id]} #{Rails.logger.to_yaml}</pre>"
  end

  def divided_by_zero
    self.response_body = "<h1>You divided by zero. This is not allowed as you may break all of physics."
  end
end

Redirecting just creates a simple #redirect_to function that creates all the HTTP parts necessary to redirect a browser to a different page. (For the SEOers in the crowd, by default it’s a 302 Found or temporary redirect, you can set it to 301 Moved Permanently or 303 Other if you so desire.)

UrlFor is a special class that helps you create URLs from your list of routes and the current route you are using. Note in the above it says :action=>:show, :id=>”butts”, (which I’m unsure why I used the older hash rocket style, but it’s a habit). In that case, it doesn’t define a controller so the UrlFor assumes that the controller is the one that I’m on. If you use redirect_to :id=>”butts2″ while in the #show action, then it’s the same as redirect_to :controller=>”mainpage”, :action=>”show”, :id=>”butts2″ since it will assume the same route elements for the ones that are missing. Very useful for dynamic URL making.

There’s a few more modules we could add, but it’s better to look at the code and read about it since those are more “as you need it”:

• HttpAuthentication: Allows you to set a HTTP user/password system managed by Rails (vs. being managed by the HTTP server or forwarder)
• DataStreaming: Allows you to send files to the browser, either hosted and read directly by the forwarder, sent directly to Rack as a large string, or create dynamically generated files to force the browser to download (such as CSV files).
• Streaming: A still-in-progress addition that allows one to render partials of a page. For example, render the top part with the CSS and Javascript, send that to the browser to chew on early, then render the rest of the page to send to the browser. Still requires lots of specialized support (ie. most middlewares and servers don’t support it), but pretty cool if it all fits together.
• ForceSSL: A simple helper that enforces page loads over SSL and redirects if not on SSL. Useful for password pages and such.
• Cookies: (actual documentation here), Simple cookie handling if for some reason you need tons of random cookies. (Note that we’ll be using Rail’s built-in session management to handle cookies for us, so you don’t explicitly need this. This is only if you want raw cookie access)
• ConditionalGet: This handles HTTP caching on the user’s browser side. For example, you can tell a browser to keep a copy on a user’s computer and not download, thus saving time and bandwidth.

That’s some of the magic functions and defaults available to a Controller. As you can see, these functions mostly just get and set various HTTP information for you. Next time, we’ll be rendering. No longer will the view data be in the in controller, we’ll put that into it’s own file with it’s own logic. Yay! (Also Session Management to store data in cookies.)

As usual, working code for this part is available here: https://github.com/ROFISH/ruby_for_programmers/tree/master/13

]]> http://rofish.net/2014/01/ruby-for-programmers-part-12-totally-metal/ Mon, 13 Jan 2014 07:27:28 +0000 http://rofish.net/?p=135 Continue reading →]]> Earlier, we briefly went over the controller as a way to store the methods of routes, but there’s way more to it then returning a bunch of status codes and headers. So now we’re going to add another piece of the pie, the ActionController, which is actually three different classes in increasing complexity, the AbstractController, the Metal, and the ActionController.

The AbstractController::Base just contains a base set of functions and modules that help out. Normally one wouldn’t make an AbstractController::Base, but this is just for show. So here’s our AbstractController:

class MainpageController < AbstractController::Base
  def self.action(method)
    lambda do |env|
      controller = new
      controller.env = env
      controller.process(method)
    end
  end

  attr_accessor :env

  def index
    [200, {"Content-Type" => "text/html"}, ["<h1>Front Page</h1>"]]
  end

  def show
    [200, {"Content-Type" => "text/html"}, ["<pre>asdf #{env['action_dispatch.request.path_parameters'][:id]}</pre>"]]
  end
end

So that doesn’t look much different then before. We still have to make our own self.action method. But we now have access to a few cool built-ins, the most important of which is the callback:

class MainpageController < AbstractController::Base
  def self.action(method)
    lambda do |env|
      controller = new
      controller.env = env
      controller.process(method)
    end
  end

  include AbstractController::Callbacks

  attr_accessor :env
  before_filter :doing_stuff

  def doing_stuff
    @hi = 'sup'
  end

  def index
    [200, {"Content-Type" => "text/html"}, ["<h1>Front Page #{@hi}</h1>"]]
  end

  def show
    [200, {"Content-Type" => "text/html"}, ["<pre>asdf #{env['action_dispatch.request.path_parameters'][:id]} #{@hi}</pre>"]]
  end
end

What it does, is allows a function to operate before all functions. On both pages, @hi is set. This is useful for tons of things like session management, page view counts, etc.

But, we still have to do that goofy array, so let’s get rid of it… with Metal. \__/

The ActionController Metal the base class that simply does what we already do with the array format and the action handle, but adds some sprinkles to make it look better. It’s only 235 lines long and doesn’t include much fluff.

So here’s our totally Metal controller:

class MainpageController < ActionController::Metal
  include AbstractController::Callbacks

  before_filter :doing_stuff

  def doing_stuff
    @hi = 'sup'
  end

  def index
    self.response_body = "<h1>Front Page #{@hi}</h1>"
  end

  def show
    self.response_body = "<pre>asdf #{env['action_dispatch.request.path_parameters'][:id]} #{@hi}</pre>"
  end
end

All the Metal really does is abstract out the env and the array, and also by default sets the content-type to ‘text/html’. Which is still a bonus because this controller is now starting to look good. It’s got some basic includes at the top, and just responds with basic text. At this point, all we did was abstract out the basics even more. Outside of including modules (like the Callback), the Metal is just a fancier version of our starting basic controller that’s not part of any class.

The Metal alone is perfectly serviceable, and some people prefer to use it. History lesson: the Rails Metal comes from the merge of Rails and Merb, where Merb was a from-the-ground-up system with plugins like I’m showing here.

Since we’re (mostly) done with abstracting out how to build a webpage, the next few segments will focus on the ‘batteries included’ part of Rails.

A couple of extra notes about callbacks, first you can limit the callback, or even skip the callback, to specific functions. Just add the array of the functions:

before_filter :doing_stuff, only:[:index]
before_filter :doing_stuff, except:[:show]
skip_before_filter :doing_stuff

Skipping filters is useful for hierarchical class inheritance.

Also, when a callback returns with a response_body (or renders or redirects as we’ll see later), it skips the rest of the call stream. For example this:

class MainpageController < ActionController::Metal
  include AbstractController::Callbacks

  before_filter :doing_stuff, only:[:index]
  before_filter :doing_stuff, except:[:show]
  skip_before_filter :doing_stuff

  def doing_stuff
    @hi = 'sup'
    self.response_body = "mystery callback"
  end

  def index
    self.response_body = "<h1>Front Page #{@hi}</h1>"
  end

  def show
    self.response_body = "<pre>asdf #{env['action_dispatch.request.path_parameters'][:id]} #{@hi}</pre>"
  end
end

Would always render “mystery callback” onto a page and never even run the #index or #show functions. This is another useful thing to be mindful of, and yet another powerful feature. For example, if you want to enforce a user login, then all you have to do is check if the user is logged in, and if not, redirect them to the login page. It will both not run the code they cannot use (since they are not logged in) and it will redirect them to a page where they can login. Useful!

]]> http://rofish.net/2014/01/ruby-for-programmers-part-11-railtying-it-together/ Mon, 06 Jan 2014 05:47:03 +0000 http://rofish.net/?p=130 Continue reading →]]> Having all this on one script is okay for now, but it’s best to start splitting up files just to make it easier to follow. So let’s create some folder conventions for us:
• app/controllers will contain our controllers as determined by our routes
• config/routes.rb will contain the routes drawer
• config/boot.rb will contain the boot script
• config/application.rb will contain information specific to our application, and hold information between files.
• config/environment.rb will have the initializers after our application.
• public/ will contain public files like CSS or error files

So first in boot.rb we’ll put the require ‘bundler/setup’. Since it’s in another folder, we’re going to need to tell that the file is in another castle:

# Set up gems listed in the Gemfile.
ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../../Gemfile', __FILE__)

require 'bundler/setup' if File.exist?(ENV['BUNDLE_GEMFILE'])

# some more requires
require 'yaml'
require 'action_dispatch'

module Rails
  class << self
    attr_accessor :application
  end

  class Application
    attr_accessor :routes

    class << self
      def inherited(base)
        super
        Rails.application ||= base.instance
      end

      def instance
        @instance ||= new
      end
    end

    def routes
      @routes ||= ActionDispatch::Routing::RouteSet.new
      @routes.append(&Proc.new) if block_given?
      @routes
    end
  end
end

ENV is a sweet built-in Ruby variable that contains the shell environment variables. This is useful if you want to store different configurations for different setups. Instead of different that may or may not be uploaded, it’s far better to store this information in an environment variable. You can setup this on the server so as to hide passwords or API keys too.

Below that is a really short version of the Rails application initializer. So we created a Rails module (for now think of modules as function containers), and made it so that Rails.application is accessible from anywhere. We then created a class named Application and used a Ruby auto-function named “inherited” where if a new class is made, it will run that function. In this case it sets Rails.application to a new instance of the child class. (If you’re confused, don’t worry, this is all automagicked away soon).

We also create the routes and the routes file:

Rails.application.routes.draw do
  get '/' => 'mainpage#index'
  get '/page/:id' => 'mainpage#show'
end

Which is just a copy/paste of our original routes. Note that it uses our Rails.application that was created, which means we need to create the child class to be inherited and instanced:

require File.expand_path('../boot', __FILE__)

Bundler.require

module GenericCMS
  class Application < Rails::Application
    # you could put some custom stuff here if you wanted
  end
end

require File.expand_path('../../app/controllers/mainpage_controller', __FILE__)

Pretty boring here except this is where we create the class to be inherited. It also requires the boot file and mainpage_controller.rb file here too. mainpage_controller.rb itself is just a copy/paste:

class MainpageController
  def self.action(method)
    controller = self.new
    controller.method(method.to_sym)
  end

  def index(env)
    [200, {"Content-Type" => "text/html"}, ["<h1>Front Page</h1>"]]
  end

  def show(env)
    [200, {"Content-Type" => "text/html"}, ["<pre>#{env['action_dispatch.request.path_parameters'][:id]}</pre>"]]
  end
end

Exactly like the old one.

For now, our environment.rb will just include the application and the routes file:

# Load the Rails application.
require File.expand_path('../application', __FILE__)

# Load the Routes
require File.expand_path('../routes', __FILE__)

And config.ru will just include the environment.rb and run the routes:

# This file is used by Rack-based servers to start the application.

require ::File.expand_path('../config/environment',  __FILE__)
run Rails.application.routes

This boots and shows the same stuff as before with our routes.

You can view the working example here: https://github.com/ROFISH/ruby_for_programmers/tree/master/11/01_folder_structure

Now before I go, there’s a reason why all this moving around, it’s just to show how Rails ties things together. In fact, the gem that holds all this together is “railties”. So let’s add it to our Gemfile, and update our scripts to use it:

ruby '2.1.0'
source 'https://rubygems.org'
gem 'rack', '~>1.5.2'
gem 'actionpack', '~> 4.1.0.beta1'
gem 'railties', '~> 4.1.0.beta1'

And run bundle install. Now we only need to make a few small changes to a few files. boot.rb will get it’s Rails stuff removed since it’s now handled in the railties gem:

# Set up gems listed in the Gemfile.
ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../../Gemfile', __FILE__)

require 'bundler/setup' if File.exist?(ENV['BUNDLE_GEMFILE'])

environment.rb now tells Rails to initialize (which will auto-load important files like routes.rb):

# Load the Rails application.
require File.expand_path('../application', __FILE__)

# Initialize the Rails application.
Rails.application.initialize!

And config.ru will run Rails.application instead of the routes, since Rails will handle some automagic for us:

# This file is used by Rack-based servers to start the application.

require ::File.expand_path('../config/environment',  __FILE__)
run Rails.application

Since railties will automatically load the controller files for us, we just need to make a couple small modifications to our application.rb file:

require File.expand_path('../boot', __FILE__)

require 'rails'
require 'action_controller' #this only here as Rails complains if it's not available

Bundler.require

module GenericCMS
  class Application < Rails::Application
    # you could put some custom stuff here if you wanted

    config.secret_key_base = "rails really wants this to be defined"
  end
end

We tell it to look for Rails and ActionController (which is next lesson, but railties/routing was whiny without it). Also, we started on the config because Rails complained without it.

And it works. bundle exec rackup will boot your app and it will still work like before, but now running on Rails. Once you load, you’ll notice it whining about eager_loading, so lets add an environment file config/environments/development.rb:

Rails.application.configure do
  # Settings specified here will take precedence over those in config/application.rb.

  # In the development environment your application's code is reloaded on
  # every request. This slows down response time but is perfect for development
  # since you don't have to restart the web server when you make code changes.
  config.cache_classes = false

  # Do not eager load code on boot.
  config.eager_load = false

  # Show full error reports and disable caching.
  config.consider_all_requests_local       = true
  #config.action_controller.perform_caching = false

  # Don't care if the mailer can't send.
  #config.action_mailer.raise_delivery_errors = false

  # Print deprecation notices to the Rails logger.
  config.active_support.deprecation = :log

  # Raise an error on page load if there are pending migrations.
  #config.active_record.migration_error = :page_load

  # Debug mode disables concatenation and preprocessing of assets.
  # This option may cause significant delays in view rendering with a large
  # number of complex assets.
  #config.assets.debug = true
end

You can ignore the actual settings until we need to go for them. However, this file is important because it defines some of the eager loading that makes Rails great. We’ll also add the default Rakefile too, while we’re at it.

Now you can run the app a different way bundle exec rails server. This boots the server a different way, but has all trimmings. rackup still works, but the rails server has better logging and debug files.

So this lesson just really moved things around, which is nice. But the controllers are still using the weird array output and a bad way to create HTML. So next lesson, let’s add some ActionControllers with some ActionViews.

The final code for this part is here: https://github.com/ROFISH/ruby_for_programmers/tree/master/11/02_railties

]]> http://rofish.net/2014/01/ruby-for-programmers-part-10-actionpacked-routing/ Mon, 06 Jan 2014 05:06:07 +0000 http://rofish.net/?p=123 Continue reading →]]> So as we saw in the last part, having different pages might end up being a slight pain, so let’s add some routing. First we’re going to need the actionpack gem, so lets add that to our Gemfile:

ruby '2.1.0'
source 'https://rubygems.org'
gem 'rack', '~>1.5.2'
gem "actionpack", "~> 4.1.0.beta1"

Note that we’re going to be using the latest beta version because by the time this is done, the new version will be out.

Run bundle install to install your new gem.

Resolving dependencies...
Using i18n (0.6.9)
Using json (1.8.1)
Using minitest (5.2.0)
Using atomic (1.1.14)
Using thread_safe (0.1.3)
Using tzinfo (1.1.0)
Using activesupport (4.1.0.beta1)
Using builder (3.2.2)
Using erubis (2.7.0)
Using actionview (4.1.0.beta1)
Using rack (1.5.2)
Using rack-test (0.6.2)
Using actionpack (4.1.0.beta1)
Using bundler (1.5.1)
Your bundle is complete!
Use `bundle show [gemname]` to see where a bundled gem is installed.

Woah, that’s a lot of dependencies! We’ll eventually get to them as needed. But for now, we’re just going to include the routing part.

The config.ru allows the use of Middleware, or something that’s run before your app. So if you wish to use a something that automates something before every page call, such as routing, then you can make a Middleware. For a simple example, look at what happens when there’s an error in your code:

require 'rubygems'
require 'bundler/setup'
require 'yaml'

run Proc.new {|env|
  if env["PATH_INFO"] == "/"
    seymour.butts
    [200, {"Content-Type" => "text/html"}, ["<h1>Front Page</h1>"]]
  else
    [404, {"Content-Type" => "text/html"}, ["<h1>Not Found</h1>"]]
  end
}

Load that in your browser via bundle exec rackup. It will show the default Rack error page. But what if you want a fancier page? There’s a middleware for that: ActionDispatch::ShowExceptions . It will allow us to show webpages to status errors so that the end-user doesn’t see code errors. It’s real simple to add, first add the files to a new folder “public”, and individual status codes like so:



You can get the HTML for those pages in the public example on Github.

Why is the folder called “public”? Because I said so. (It’s a Rails convention actually.)

Then add the following to your config.ru:

require 'rubygems'
require 'bundler/setup'
require 'yaml'

require 'action_dispatch'

use ActionDispatch::ShowExceptions, ActionDispatch::PublicExceptions.new("public/")
run Proc.new {|env|
  if env["PATH_INFO"] == "/"
    seymour.butts
    [200, {"Content-Type" => "text/html"}, ["<h1>Front Page</h1>"]]
  else
    [404, {"Content-Type" => "text/html"}, ["<h1>Not Found</h1>"]]
  end
}

The new line means to use the middleware ActionDispatch::ShowExceptions, with the argument of “ActionDispatch::PublicExceptions.new(“public/”)”. In this case, ActionDispatch::ShowExceptions requires a secondary middleware to route to actually show the exception. The “public/” of course means to look for any files in our newly created public folder.

Then load your front page. It should now have a prettier error page:



It’s the little things that count.

So lets add some routing, so here’s our updated config.ru file:

require 'rubygems'
require 'bundler/setup'
require 'yaml'

require 'action_dispatch'

routes = ActionDispatch::Routing::RouteSet.new

routes.draw do
  get '/' => 'mainpage#index'
  get '/page/:id' => 'mainpage#show'
end

class MainpageController
  def self.action(method)
    controller = self.new
    controller.method(method.to_sym)
  end

  def index(env)
    [200, {"Content-Type" => "text/html"}, ["<h1>Front Page</h1>"]]
  end

  def show(env)
    [200, {"Content-Type" => "text/html"}, ["<pre>#{env['action_dispatch.request.path_parameters'][:id]}</pre>"]]
  end
end

use ActionDispatch::ShowExceptions, ActionDispatch::PublicExceptions.new("public/")
use ActionDispatch::DebugExceptions
run routes

So let’s go over what we did. First, we created a new RouteSet, which is fine, and then started to draw some routes. Notice how the routes mention a “mainpage#index” or “mainpage#show”? It means that to route that to a MainpageController#index or MainpageController#show action. Why does it add Controller to the class name? Because I say so.

On the MainpageController is a self.action handler to handle the route internals by creating a new instance. And the individual methods now look like before with the status, header, body like in the other example.

Towards the end we add ActionDispatch::DebugExceptions to show the errors in the log in our terminal, because errors are now hidden from the browser. And finally, our app is no longer a function but rather the routes we created (which will forward to it’s respective controller).

Anyway, the routes are exactly like Rails routes, so a better documentation was written in the Rails Guide. There is some fancy pants stuff other than generating each individual route, like “namespace” which allows you to create namespaced controllers (like Admin::PostController for an admin interface), “resources” which creates the standard routes for an object (index, show, new, edit, create, update, destroy), and constraints by regex, subdomain, and more.

We’ll be going over the part of routes we’ll be adding as we add them. This just shows how routes fits in the whole scheme.

Download the working example code here: https://github.com/ROFISH/ruby_for_programmers/tree/master/10

]]> http://rofish.net/2014/01/ruby-for-programmers-part-9-making-pages-with-bundler-and-rack/ Mon, 06 Jan 2014 00:34:26 +0000 http://rofish.net/?p=118 Continue reading →]]> So ends the really basic tutorial. There’s still tons more stuff to go over, like Modules and Mixins, Monkeypatching, Begin/Rescue/Ensure, but we’ll get to those basics as we come to them. If you really want to learn some deep dark mysteries, I suggest reading the Pickaxe Book. It’s a complete, unabridged, and also includes information about the standard library too.

So for now, we’re going to focus on creating a web app with Rails. There are other Ruby-based frameworks like Sinatra, we’re going to be focusing on Rails since it’s got, at least in my opinion, the right amount automagic for what we’re going to build. (Of course one could argue that Node or Java or some other language would be better. That’s not the scope of this, but to learn Rails.)

I’ve always found it better to learn Rails from the ground-up from its parts rather than a “here’s all the random things it can do!” that’s in most docs/tutorials. So to build a webpage from scratch, you must first invent the universe.

In which case, you must start with a Gemfile and Bundler. In the dayes of olde, gems were not included with Ruby, but rather a separate installation. These days, it’s included with the Ruby source as part of a standard installation. However, what’s missing is a package version manager, which is Bundler. You can install bundler as you would any other gem:

gem install bundler

Bundler ensures that everybody is running the same version of gem as you, which is very important as APIs and functions changes, and helps ensure security updates by listing gem versions.

So for now, we’re going to create a Gemfile in our project and list Rack as a gem:

ruby '2.1.0'
source 'https://rubygems.org'
gem 'rack', '~>1.5.2'

Bundler allows a bunch of configuration options in the Gemfile (which can be read in the Bundler docs). To note the current lines, the first tells Bundler to enforce a Ruby version. This is slightly helpful if you have a custom installation on a server, but especially helpful on cloud services like Heroku which otherwise wouldn’t know which Ruby version to use. (You don’t automatically want to use the latest and greatest because it might introduce bugs.) The second determines where the gems will download from (always rubygems.org). Then list the gems by name, and optionally by version. You can do the normal >, >=, <, <= tags, but ~> is special. It means that “incrementing the last number is okay, but not the others”. In this case Bundler can safely install 1.5.2, 1.5.3, 1.5.1052, but not 1.6.0. Also note that when installing on a server, Bundler will install the exact gem version you have from the Gemfile.lock file.

To install your gems just run bundle install from where your Gemfile is. This will create the Gemfile.lock which will tell servers and other programmers which version to use. If you’re missing a version, running bundle install will install it. If you wish to change a version, update the Gemfile and run bundle update rack or whatever the name of the gem to update. This will re-run the dependency check and put the new version in.

Once you have Rack installed, now it’s time to use it. While Rack can be called from a method like anything else, Rack apps typically have a “config.ru” file which is just a special file it looks for to operate.

So to create our first Rack app, just insert the following into a new config.ru file:

require 'rubygems'
require 'bundler/setup'

run Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["<h1>Hello Rack!</h1>"]]}

The first two lines tells Ruby to include rubygems, a holdover from the previously said days where gems is not included but good to do anyway. The second runs the Gemfile and includes all of its requested gems. Then we tell Rack to run a very simple app, which is already returned as an array with three elements: the HTTP status code (200 for page info, 404 for not found, etc.), the headers in a Hash, then the body of the response. Note that the body of the response has to respond to #each for metaprogramming and lazy-loading reasons we’ll go over later. Just for now, let’s make it a single element Array with a String.

To run your app, just run bundle exec rackup on the command line. (Bundle also ensures that you run the right version from the command line too, how nice!) Then just open your browser to localhost:9292 (or whichever port it chooses), and your page now loads! Nice, neat, easy simple. Except that every page is the same. Lets view what’s in the env variable:

require 'rubygems'
require 'bundler/setup'
require 'yaml'

run Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["<pre>#{env.to_yaml}</pre>"]]}

Quit your app and restart to load new code. Reload the page to view all kinds of wonderful information:

---
GATEWAY_INTERFACE: CGI/1.1
PATH_INFO: "/"
QUERY_STRING: ''
REMOTE_ADDR: 127.0.0.1
REMOTE_HOST: localhost
REQUEST_METHOD: GET
REQUEST_URI: http://localhost:9292/
SCRIPT_NAME: ''
SERVER_NAME: localhost
SERVER_PORT: '9292'
SERVER_PROTOCOL: HTTP/1.1
SERVER_SOFTWARE: WEBrick/1.3.1 (Ruby/2.1.0/2013-12-25)
HTTP_HOST: localhost:9292
HTTP_USER_AGENT: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101
  Firefox/26.0
HTTP_ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
HTTP_ACCEPT_LANGUAGE: en-us,en;q=0.5
HTTP_ACCEPT_ENCODING: gzip, deflate
HTTP_CONNECTION: keep-alive
HTTP_CACHE_CONTROL: max-age=0
rack.version:
- 1
- 2
rack.input: !ruby/object:Rack::Lint::InputWrapper
  input: !ruby/object:StringIO {}
rack.errors: !ruby/object:Rack::Lint::ErrorWrapper
  error: !ruby/object:IO {}
rack.multithread: true
rack.multiprocess: false
rack.run_once: false
rack.url_scheme: http
HTTP_VERSION: HTTP/1.1
REQUEST_PATH: "/"

So from here we can get the path requested and do things if we wanted to, like this:

require 'rubygems'
require 'bundler/setup'
require 'yaml'

run Proc.new {|env|
  if env["PATH_INFO"] == "/"
    [200, {"Content-Type" => "text/html"}, ["<h1>Front Page</h1>"]]
  else
    [404, {"Content-Type" => "text/html"}, ["<h1>Not Found</h1>"]]
  end
}

It’s not pretty, but it does either show front page if you go to http://localhost:9292/ and a 404 error if you go to http://localhost:9292/asdf.

So right here off the bat, it’s going to show lots of things that are different if you are coming from a generic PHP side of things. PHP is generally a server plugin that operates based on which file is being requested. Even if you’re doing mod_rewrite stuff, it still generally just requests a file. Any changes to the file is fine, as the script is run on each page load.

Here though, it’s an app in the background that accepts a real HTTP connection. The app has to be running and any changes requires a restart of the app. It’s more of a tradeoff though: Large apps can keep it’s compiled code in memory and respond quicker vs. parsing scripting on each page load. For Ruby, since the code parsing for large apps is fairly slow, the server model is used.

Not all is lost, you can simply put your app behind a reverse proxy (Apache instructions, Nginx instructions). Now using straight Rackup and WEBrick (Ruby’s included web server in ruby) is not a good idea on the deploy-side. There’s better options for those that run your own servers, like Unicorn, Puma, Passenger, the latter available in both open-source and enterprise editions, and Heroku, Docker, and AWS Beanstalk on the cloud-side. We’ll be mostly focusing on app building rather than deployment for the most part.

]]>