A Brief Introduction to Decent Exposure – A helper for creating declarative interfaces in Rails controllers

View Github Repository Open presentation in a new window

dougalcorn

See all presentation from dougalcorn

A Brief Introduction to Decent Exposure – A helper for creating declarative interfaces in Rails controllers

1 0

decent_exposure_pres

A Brief Introduction to Decent Exposure

On Github dougalcorn / decent_exposure_pres

A Brief Introduction to Decent Exposure

A helper for creating declarative interfaces in Rails controllers

Doug Alcorn, doug@gaslight.co

Scaffolding

class EmployeesController < ApplicationController
  before_filter :get_company                            

  def index
    @employees = @company.employees.all
  end

  private

  def get_company
    @company = Company.find(params[:company_id])
  end
end
Here we have a before filter setting an instance variable used by the entire controller. We're further assigning an instance variable in the action. Before filters are somewhat hard to test and are easily forgotten. Also, you'll eventually find yourself scoping filters with :only or :except; which is yucky.

Instance Variables in Views

Hi, <%= @employee.name %>
In object-oriented programming, an object uses instance variables to store private information. If you want to access an object’s instance variables, those variables should only be accessible through instance methods. At least, this is the expectation.

Declarative Helper Methods

class EmployeesController < ApplicationController

  helper_method :employees, :company

  def index; end

  protected

  def company
    @company ||= Company.find(params[:company_id])
  end

  def employees
    @employees ||= company.employees.all
  end
end
Here we have two helper methods that encapsulate how to initialize the needed instance variables. They are cached so that the SQL only happens on the first access. In the view you can just call company or employees to access those instances rather than the @company instance variable. The really good news here is that if you decide to refactor how the employees are accessed (like scoping it to "active" employees), it's easy to change in just one place. Also, since the helper methods do all the initialization, there's no actual code needed in the index action and it can go away. Finally, these helper methods are easy to stub out in testing to avoid hitting the database during controller specs.

Trickier Example

def employee
  @employee ||= if params[:id]
    Employee.find params[:id]
  else
    Employee.new params[:employee]
  end
end
Here we see that the singular instance of employee is either initialized with it's id if it's passed in as a param (as in the show action) or it's newed up with passed in attributes (as in the create attribute). What we can see is there there are lots of corner cases that need to be thought through.

Decent Exposure

class EmployeesController < ApplicationController
  expose(:company)
  expose(:employees) { company.employees.all }
  expose(:employee)
end
Here we're using decent exposure's expose method to create helper methods similar to our hand rolled helpers. Without any arguments, they do a pretty "decent" job of guessing what it should do to load the resource. With an optional block you can specify how the resource should be defined.

More Info

◄►▲▼