From the monthly archives: October 2007

The problem:

Having logic in your view is bad. Putting some in the helpers can help. Some methods can be put on the model. Sometimes, your view involves a couple of models, the helpers get bigger, you’re not sure on which model to put a method as it needs data on a few of the associations. The view is getting ugly, you have to go through pages of helper methods to find things. You’re feeling dirty.

The solution:

Move all the methods related to one of the view to a class (the presenter). Create it in the controller by passing it all the objects it needs to manipulate. Change your view to only call methods on your @presenter.


You will probably want to have access to the ActionView::Helpers::* in your presenter so it can useful to declare a base presenter class you will inherit from like this:

class Presenter
  include ActionView::Helpers::TagHelper
  include ActionView::Helpers::FormHelper
  include ActionView::Helpers::FormTagHelper
  include ActionView::Helpers::FormOptionsHelper
  include ActionView::Helpers::DateHelper
  include ActionView::Helpers::JavascriptHelper
  include ActionView::Helpers::AssetTagHelper

  def intialize(controller)
    @controller = controller

Some helpers need the @controller to do their magic.

Success stories:

I’ve used this approach two times now. Last time, I had a view that showed deeply nested data (parent => children => children => children). There were a bunch a checkboxes that needed to be all checked/unchecked at the same time depending on which element was clicked. Putting all the methods required to generate the checkboxes with ids and class and restoring that from the params in case of an error was ugly. However, that ugliness was nicely sealed in a class that prevented infection of the rest of the code.

Further links:


The approach I described here may not fit the original presenter pattern as described in those other links. What’s important here is, if your view is getting ugly, hard to test, you have too many helpers, or the code is starting to smell, you can move stuff to a new class. This may seem evident, but I sometimes feel people using rails forget that you can do stuff “outside” of the way rails normally structure a project. Also note that the presenter pattern is definitely not something you need for every project.

Popularity: 10% [?]


Last night’s Montreal on Rails was once again a fun event with three great presentations. Standout Jobs hosted the event in their new offices (quite nice btw).

Gary Haran on Prototype

Gary gave a very interesting tutorial on the basics of using the Prototype javascript framework. I learned quite a few things. Prototype’s doc seems to have really improved in the last year and I should probably learn it, instead of living in fear of writing javascript. Someone mentioned that prototype modifies directly some standard classes and can break other libraries. It’s something you should be aware of.

I would like to see a followup to this presentation, with more advanced prototype stuff and a how to properly write a class.

Francois Beausoleil on Piston

Francois is the author of Piston and presented it in a very succinct way. It’s a tool to help you manage your svn:externals (you probably have a few in your plugin directory). I like it: simple tool that solves a very real problem (breaking your deployment because a remote repository is down).

James Golick on make_resourceful and shoulda

James presented two useful plugins. make_resourceful is like dynamic scaffold for restful controllers on crack. It has a whole bunch of callbacks and things to override to easily customize parts of the controller. shoulda provides lots of test helpers, helpers for validation, model association and restful controllers. That last one is a really nice complement to make_resourceful.


Montreal on Rails is a great initiative. It’s great for the presentation, the networking and it’s gonna help the raise the level of expertise of everyone involved. I heard lots of people talking how they started using things they heard about in past presentations. There’s so many plugin out there today (there’s almost too many) that every edition should have a 15 mins presentation where someone presents 2-3 plugins. See you all next time!

Popularity: 13% [?]