Sometimes, a design requires a little extra markup, perhaps something to get that rounded corner to work or what-have you. Now let’s say this piece of code requires certain classes, a certain kind of structure, including a tile, and has to be used in many places, something like a sidebar piece. Instead of copying and pasting this structure over and over, you can use a helper to make you life easier, and if you combine it with a block, it will just feel even more painless.

The Setup

<div class="sidebar">
  <div class="bottom">
    <h3>Title</h3>
    <div class="body">
      <p>Some Content</p>
    </div>
  </div>
</div>

There are two elements which must change; the title and the contents of the body. The title should simply be just some text that goes in between the h3 tag. The contents of the body could be anything, in this case, it is the paragraph tag and everything inside.

Creating a Helper without a Block

Since we have these two varying things, we could create a helper method to encapsulate our structure. The first parameter of the helper will be the title while the second parameter will be the contents of the body.

def sidebar(title, body)
  content_tag(
    'div',
    content_tag(
      'div',
      content_tag('h3', title) + content_tag('div', body, :class => 'body'),
      :class => 'bottom'
    ),
    :class => 'sidebar'
  )
end

That looks pretty easy. Now let’s look at the interface for this helper

<%= sidebar('Hello World',
  '<p>It is one of these "Hello World" things again.</p>') %>

Not too shabby, but what if we wanted to do an unordered list?

<%= sidebar(
  'Hello World',
  '<ul>' +
    '<li>Item</li>' +
    '<li>Item</li>' +
    '<li>Item</li>' +
  '</ul>'
) %>

This feels pretty clunky and ERB is completely ignored. Instead of this procedural way of thinking, why not see what a block can do for us?

Creating a Helper +with+ a Block

For this to work, we will still need the first parameter to be the title, but the body will be passed in as a block to be processed from within our helper. The block we create will be ERB code, this will feel more natural to the person who has to implement the code. The magic to get this done comes from the concat method of ActionView::Helpers::TextHelper module.

def sidebar(title, &block)
  raise ArgumentError, "Missing block" unless block_given?

  start = <<-END
    <div class="sidebar">
      <div class="bottom">
        <h3>#{title}</h3>
        <div class="body">
  END
  concat(start, block.binding)

  block.call

  end = <<-END
        </div>
      </div>
    </div>
  END
  concat(end, block.binding)

end

This may look slightly odd, but I assure you, the interface makes up for it.

<% sidebar('Hello World') do %>
  <p>And now back to the way I was doing things before</p>
  <ul>
    <li>Item</li>
    <li>Item</li>
    <li>Item</li>
  </ul>
<% end %>

The Benefits

• The implementation code is more readable
• It gives you one place to make your common edits
• It keeps your code DRY(don’t repeat yourself)

def index
  @articles = Article.find(:all)
  respond_to do |format|
    format.html
    format.xml { render :xml => @articles.to_xml }
  end
end

def show
  @article = Article.find(params[:id])
  respond_to do |format|
    format.html
    format.xml { render :xml => @article.to_xml }
  end
end

If we want to use the respond_to, we have to make sure it’s in all of our methods. Wouldn’t it be easier to just do something like this?

def index
  @articles = Article.find(:all)
  format.html
  format.xml { render :xml => @articles.to_xml }
end

Doing it this way, we don’t have to write 2 extra lines per method, and we don’t increase our indentation. While that’s not a huge thing, I still just don’t like to constantly write out those lines when I don’t have to when I think we can build something a little trickier.

The Breakdown

In the simplified example I gave above, we have several things that we need to accomplish. One is to wrap our methods with a respond_to by using alias_method Well, it’s actually not that simple because respond_to is a block and we will need to do some trickery there. Another task is we need to create a format method. Since we won’t be calling format with a block parameter, we need to make a method which will do the dirty work for us. Finally, we need to make a tweak to ActionController::MimeResponders::Respond#respond for some of the other things that we are doing.

Adding wrap_respond_to_in to our ApplicationController

To start things off, we need to make a class method, which I have dubbed wrap_respond_to_in (I would love suggestions for names here).

class << self
  def wrap_respond_to_in(*actions)
    if actions.include?(:all)
      # Also remove #rescue_action because this gets set in tests. Also include some of my friendly #find methods.
      actions = actions + self.public_instance_methods - ApplicationController.public_instance_methods - ['rescue_action'] - [:all]
      [:find_collection, :find_new, :find_member].each do |finder|
        actions << finder if method_defined?(finder)
      end
    end

    # Returns the appropriate Responder format based on the action.
    define_method(:format) do
      @format.last rescue nil
    end

    for action in actions
      action = action.to_sym

      module_eval <<-END
        alias_method(:__#{action.to_i}__, :#{action.to_s})
        private :__#{action.to_i}__

        def #{action.to_s}(*args)
          result = nil      # This is the result of whatever method this wraps
          respond_to do |format|
            @format ||= []
            @format.push(format)
            result = __#{action.to_i}__(*args)
            @format.pop
          end
          return result
        end
      END
    end
  end
end

Let’s break this down by section. First things first, the method’s arguments should be a list of symbols for the names of the methods we would like to use our respond_to shorthand. Because I would like to use this shorthand for all of my action methods, I have included the notion of sending :all as a parameter. This will make sure that all of the public methods and some protected methods that I use (find_member, find_collection, and find_new). Again, I like to keep things DRY(Don’t Repeat Yourself). Next we define a method called format. This will be an accessor to the last element of our format instance variable array. More on this later. After we have defined that, we need to loop through all of our methods that we want to use respond_to. In each loop, we need to make an alias for our methods. This is so that we can re-write the method, yet still keep a copy of the original code. Next we overwrite the method. As you can see here, this is where we put the respond_to block. Now in this block, we have access to the format variable. Next we push this value into our format instance variable. The reasoning for using an array is to accommodate for a nested set of calls. After we push format onto format, we then call our original method, which uses the shorthand and save that to to a variable. Once that is done, we pop off the last value we put into the format@ variable, since we are done with it. Finally, return the result of our original method. This is the backbone for what we need to do. Now we need to implement it.

Tweaking ActionController::MimeResponds::Responder

Because we now have assumed that all of our methods are going to use respond_to, we need to make a way out if for some reason we don’t need to use said method. This would mean that our method exists without calling the format method. In order to do that, we can use the following code:

module ActionController #:nodoc:
  module MimeResponds #:nodoc:
    class Responder
      alias_method :__respond_without_check_for_empty_order__, :respond
      private :__respond_without_check_for_empty_order__

      def respond
        return if @order.empty?
        __respond_and_check_for_empty_order__
      end
    end
  end
end

We simply do a check to see if order is empty. If so, that means our format method was never called, so we just simply need to exit out of the respond method. I put this in my lib directory and make sure that my app requires this after rails has been loaded.

Using wrap_respond_to_in

Quite simply all we need to do to use it is to call it, but we must do so after we have defined all of our methods for which we want to use this technique

.

class Articles < ApplicationController
  before_filter :find_member, :only => [:show]

  def show
    format.html
    format.xml { render :xml => @article.to_xml }
  end

  protected
    def find_member
      @article = Article.find(params[:id])
    rescue ActiveRecord::RecordNotFound
      format.html do
        flash[:error] = "Article was not found"
        redirect_to articles_url
      end
      format.xml { head :status => 404 }
    end

    wrap_respond_to_in :all
end

While this is not a complete controller, it does show you how to use it.

Final Words

There’s no reason to put a respond_to call in all of the methods when there is a way around it. Once I figure out how to get SVN(subversion) working with Dreamhost I am going to put this into a plugin for all to use.

If you want to do the latter, then there are two lines you my want to put at the top of your script.

ENV['RAILS_ENV'] = ARGV.first || ENV['RAILS_ENV'] || 'development'
require File.expand_path(File.dirname(__FILE__) + "/../config/environment")

The first line allows us to supply which environment we would like to run the script in. Say the script is called process.rb, we could call the script like ./process.rb production and now the environment is set to production.

The second line loads the environment file. Now all of rails, your models, libraries, and plugins are available to you.

Sometimes I find that I want pre-load my database with some data, like categories that I have. For testing purposes, I have already created this data in my fixture; now I just want to load that fixture into my database from a migration call.

I know that there is a rake task for this, so I looked into that code and came up with a little something.

require 'active_record/fixtures'

class CreateCategories < ActiveRecord::Migration
  def self.up
    create_table :categories do |t|
      t.column :name, :string
    end

    Fixtures.create_fixtures('test/fixtures', File.basename("categories.yml", '.*'))
  end

  def self.down
    drop_table :categories
  end
end

First I had to require active_record/fixtures. This allows me to call the Fixtures#create_fixtures method, which load my data. Now I can gaurantee that my fixture data will be loaded for any environment.

That sets of the paranoia level up because who knows, I may need 1001 migrations! So to settle this once and for all, I wrote a script that would generate 999 migrations for me. I ran the 1000 migration and then it created 1001_test1001.rb.

Good news! Rails doesn’t constrain its migrations to a 3 decimal place prefix. So pointless…

I did check it out and I have to say that I’m impressed. It is using the rails edge and is trying out some of the REST(representational state transfer)ful stuff all the while adhering to the philosophies of CRUD(create, read, update, delete). I have wanted to look into a good example of a rails project using REST, and this code base is great for that. What’s more is that it’s not very difficult to wrap your head around all of the code of the site, due to the small code base and nice abstraction of the code.

While reading up on this new forum, I came across a post in which the writer was interested in Beast because of the marketing tag-line, written in _under 500 lines_. He goes on to raise some points on why that philosophy rubs him the wrong way, but I have different views on his points.

Obscure Code

This certainly can be the case in many instances. I have seen a chat server written in 4 lines of perl code. That thing is a horrible mess. That said, I think Beast suffers no where near the extent on that. It does make use of writing out small methods to the whole line; and being that ruby can lend itself well to being understood when read aloud, it’s not that obscure. I will say that in order to read some of these lines, you will have to be somewhat familiar with the idioms of ruby

Included Libraries

Marc makes the point of noting that just because you have written 500 lines of code, doesn’t mean that the project is 500 lines of code is you use frameworks and plugins and other libraries. Mathematically, I agree; however, there is a difference in code that is apart of your project from that code abstracted to external uses. You could also then argue that 50 lines in Java is actually more because you have to think about all of the code that was used to make all of the Java classes as well as that to make the engine but that shouldn’t matter. The only thing that really matters is the 50 lines of code that are doing what you need to get the job done.

Arbitrary Restriction

It’s true, the number of lines of code really don’t matter to a machine; but to make claims that it isn’t more useful is untrue. Part of keeping code small is that it keeps it agile. One way to keep the lines of code small in number is to not rewrite functionality. Not repeating your code keeps your edits quick and you have the ability to change functionality faster. While setting the number at 500 may be weird, trying to adhere to keeping extraneous code out is a good thing. Now if the project warrents lifting that 500 line cap and then code stays committed to the 500 limit, therefor kludging up things or doing this half-assed, then that is truly absurd.

Feature loss

I do not think that you have to lose features in order to make this work. I think the restrictions can be liberating. 500 lines of code: that means there cannot be all of the bells and whistles; not until the core code is in place. In order for the forum to work, the core functionality has to be in place, and since the 500 lines are the limit, then it means that the other pieces of scope have to wait. I’m not going to say that Marc’s situation of poorly-implemented code can (and often does) happen, but I think with Beast, they have the right approach.

Beast is shaping up to be a really nice forum, something that you can use the ground work for and build higher if need be. It’s simple and elegant and a fine example of a rails project.

Notes

Perl Chat written in 4 lines

#!/usr/local/bin/perl -- minchat: run and telnet to port 5555 - bslesins
sub p{print@_}$SIG{CHLD}=sub{wait};socket S,2,2,6;bind S,pack(Snx12,2,5555);
listen S,5;while(accept C,S){if(!fork){open(STDOUT,">&C");p"name:";$n=substr
,0,-2;$f=fork||exec"tail -f chatlog";open W,">>chatlog";select(W);$|=1;p
"[$n here]\r\n";while(){p"$n> $_";}p"[$n gone]\r\n";kill 15,$f;exit}}

Tonight I found video of that presentation and I got excited about CRUD(Create, Read, Update, Delete). It pointed out that I’ve been making some controllers a little bloated. I have coupled much functionality into one controller; when looking back, I clearly could have separated out some functionality.

Learning to love has_many :through even more with CRUD

One of the points about this is that the coupling often happens when you have models that are joined by a table, like in a HABTM(has_many_and_belongs_to) relationship. The table that joins the two other tables as an amorphous name, whose role changes depending on which side of the join table you are looking. has_many :through fixes this ambiguity as it gives a name to a new model, and thus a new domain to think about creating clean uses of CRUD. An example will make this much clearer.

The non-CRUD way

class Author < ActiveRecord::Base
  has_and_belongs_to_many :books
end

class Book < ActiveRecord::Base
  has_and_belongs_to_many :authors
end

Let’s say I have a AuthorController and we want to add books to an author, or remove a book from an author, we could write the following.

class AuthorController < ApplicationController
  def add_book
  end

  def remove_book
  end
end

This doesn’t seem that harmless, but what if we wanted to add authors to a book?

class BookController < ApplicationController
  def add_author
  end

  def remove_author
  end
end

This does not follow the ways of DRY(Don’t Repeat Yourself), because depending on which side of the coin you are looking at, you have two different ways to accomplish pretty much the same thing.

Enter has_many :through

DHH points out that if we can identify the link between Authors and Books, there will be a new a less ambiguous and more elegant way to think about this issue. The link to identify here is Authorship. Now let’s change our models some.

class Author < ActiveRecord::Base
  has_many :authorships
  has_many :books, :through => :authorships
end

class Authorship < ActiveRecord::Base
  belongs_to :author
  belongs_to :book
end

class Book < ActiveRecord::Base
  has_many :authorships
  has_many :authors, :through => :authorships
end

Because the link has been identified, a controller can be created with the ideals of CRUD put right into place.

class AuthorshipController < ApplicationController
  def create
    #Authorship.create(:author_id => params[:author_id], :book => params[:book_id])
  end

  def destroy
  end
end

Everything is right with the world again

POST, GET, PUT, DELETE

The other big thing that was mentioned was mapping CRUD functionality to HTTP(hypertext transfer protocol) method definitions: POST, GET, PUT, and DELETE respectively. The HTTP method acts as the verb for what the controller should do. Here is the basic outline, the comments are how things fit into the lovely world the the HTTP methods as verbs:

class SomethingController < ApplicationController

  # POST /something
  def create
  end

  # GET /something/1
  def show
  end

  # PUT /something/1
  def update
  end

  # DELETE /people/1
  def destroy
  end

end

Since browsers don’t use PUT or DELETE, Rails has a hack for this; it’s going to send hidden fields with the actions so that the mappings know how to handle everything. Those methods aren’t the only ones that are apart of the CRUD; there are other ones that are common to most controllers:

class SomethingController < ApplicationController

  # GET /something
  def index
  end

  # GET /something;new
  def new
  end

  # GET /something/1;edit
  def edit
  end

end

index is responsible for listing all of the somethings, while new and edit are how users first start their journey to creating or updating something.

Clarity in this layout isn’t the other reason to use this. The other reason Rails is going to be embracing REST(Representational State Transfer) ideals into the way Rails will route your URLs. More on this later when I dive deeper into it.

Because of this presentation, I’m thinking about how I’m doing my controllers. I usually don’t have this type of setup, but I am definitely going to start using it. From now on, I will not be afraid do use the command script/generate controller Something index new create show edit update destroy and start to think about controllers from a CRUD perspective rather than creating more monolithic controllers, and to be ready for when Rails 1.2 comes in full effect.