27 March 2012
Real Views with Draper
I recently latched on to a tweet thread that was originated by Michael Guterl (@mguterl), in which he expressed his frustration with view helpers and erb in rails. The frustration was echoed by others, and being somewhat new to Rails, I can’t say that I’ve personally felt much pain first hand, but’s my impression from the the get-go, is that erb templates seem to get ugly quickly, and helpers aren’t properly object oriented.
On the first count, I can’t much fault erb for getting ugly. Those little are powerful, you can’t really blame the tool for providing you all the rope you need to hang yourself with. I’m kind of intrigued by the idea of logic-less templates though, in a masochistic kind of way, but maybe that’s an investigation for another blog post.
On the lack of object orientation, I’m intrigued. This seems wrong, but what is the pain point here exactly?
During the course of the thread, Chris Nelson (@superchris) mentioned he had been working with the Draper gem on a project and it had so far seemed like a win. The idea of Draper is to provide real ruby class between the template and the model where presentation concerns can reside. A view class, rather than a helper. I decided to give it a try.
My starting point was to seek out an erb template on a production project that was getting particularly ugly with logic, and see if Draper could help me clean it up. I wanted to see how much I could do with helpers, and then if an OO view could improve upon that.
Getting Started
I watched the Draper RailsCast. Installing the gem, I got a generator that I could feed an existing model class. It generated a decorator class associated to that model in a new app/decorators/ directory. The class looks like this.
class CallReportSummaryDecorator < ApplicationDecorator
decorates :call_report_summary
The Decorator is a design pattern that “attach(es) additional responsibilities to an object dynamically”. Wrapper, or Presenter is another term. Our Draper decorator is a view. It adds a layer of view related code, and delegates everything else to the model it wraps.
I instantiate the new class in the controller, that here used to return a collection of CallReportSummary objects. CallReportSummary(s) calculate and compile some metrics, and the index page displays a table of these metrics with a row for each summary.
def index
@current_tab = "Statements"
@summaries =
@users.collect { |user|
CallReportSummaryDecorator.new( CallReportSummary.new(user, @date_range))}
end
The controller now returns a collection of those objects wrapped in decorators, but the app behaves as it always has. That’s because the decorator is automatically delegating all calls to the established model through method missing. This is kind of an interesting divergence from the gang of four implementation of the decorator, which get’s it’s methods by subclassing the object it decorates.
Usage
So how do we use it?
Consider the following piece of code that renders user data from a report summary object into a table field:
<td><%= summary.display_name %><%= ghost_icon(summary.user) %></td>
With a helper we could clean it up a little like:
<td><%= display_user(summary) %></td>
But that’s where things get screwy with helpers. Maybe a functional programmer can set me straight on this someday, but it seems more suitable for display_user to be method of the summary, as opposed to a function that acts on it.
<td><%= summary.display_user %></td>
Regardless of your preference there, the fact remains that there’s no intuitive way to structure gobs of helper code, in the way that standard Ruby OOP can provide.
So, if you don’t like the helper, your next option is to put the display_user method on the model, where it doesn’t belong. Views of a model are different than the model, and you should have the capacity to view a model in different ways. Draper provides that capacity where Rails doesn’t. With decorators, you can leave the model alone, and implement display_user in a view that wraps the model. Then, you can turn around and implement display_user again as many different times, in as many different views.
The Draper decorator has access to the model it decorates through @model, and to all helper functions through the h. proxy. That includes ones you’ve defined, and standard Rails ones like link_to and content_tag.
So the implementation in the decorator just becomes:
def display_user
@model.display_name + h.ghost_icon( @model.user )
end
I guess the lesson I learned here is that Draper, to me, is not so much about cleaning up templates. That can be done with helpers and partials. So I decided to investigate more the use of Draper as a tool for good OO design.
Good Design
That user data rendering code was taken from this view that renders a table with a row for each report summary returned by the controller.
<table>
<thead>
<tr>
<th>User</th>
<th>Clicks</th>
<th>Calls</th>
<th>Convs</th>
<th>Cost</th>
<th>Cost/Click</th>
<th>Cost/Call</th>
<th>Click-To-Call</th>
<th><input type="checkbox" name="check_all" id="check_all" value="all"/></th>
</tr>
</thead>
<tbody>
<% @summaries.each do |summary| %>
<tr>
<td><%= summary.display_name %><%= ghost_icon(summary.user) %></td>
<td><%= format_number(summary.total_clicks) %></td>
<td><%= format_number(summary.total_calls) %></td>
<td><%= format_number(summary.total_conversions) %></td>
<td><%= format_microcents(summary.total_customer_cost) %></td>
<td><%= format_microcents(summary.average_customer_cpc) %></td>
<td><%= format_microcents(summary.cost_per_call) %></td>
<td><%= format_percentage(summary.calls_per_click) %></td>
<td><input type="checkbox" name=send_summary[] id=send-<%= summary.id %> value="<%= summary.id %>" class="send_summary" /></td>
</tr>
<% end %>
</tbody>
</table>
Each report row contains a checkbox that when checked and submitted, will render that single report summary object into an email statement and send it off to that particular client. The data rendered in that email statement is different from the data rendered in the above administrator’s view:
<table>
<thead>
<tr>
<th>Total Amount</th>
<th>Impressions</th>
<th>Clicks</th>
<th>Cost/Click</th>
<th>Calls</th>
<th>Convs</th>
<th>Cost/Contact</th>
<th>Click-to-Contacts</th>
<th>Average Position</th>
</tr>
<tr>
<td><%= format_microcents(@summary.total_customer_cost) %></td>
<td><%= number_with_delimiter(@summary.total_impressions.to_i) %></td>
<td><%= format_number(@summary.total_clicks) %></td>
<td><%= format_microcents(@summary.cost_per_click) %></td>
<td><%= format_number(@summary.total_calls) %></td>
<td><%= format_number(@summary.total_conversions) %></td>
<td><%= format_microcents(@summary.cost_per_call) %></td>
<td><%= format_percentage(@summary.calls_per_click) %></td>
<td><%= number_with_precision(@summary.average_pos, :precision => 2) %></td>
</tr>
</thead>
</table>
Hence, a scenario in which a particular model is displayed in two different ways. The driving idea here is that the template should not also be the view. The template should be concerned primarily with styling and markup, not with choosing the data to be displayed. We have a view decorator now that can determine that. With that in mind, my Draper-fied tables became:
<table>
<thead>
<tr>
<th>User</th>
<% table_view.table_headers.each do | table_header | %>
<th><%= table_header %></th>
<% end %>
<th><input type="checkbox" name="check_all" id="check_all" value="all"/></th>
</tr>
</thead>
<tbody>
<% @summaries.each do |summary| %>
<tr>
<td><%= summary.display_user %></td>
<% summary.attributes.each do |attribute| %>
<td><%= summary.render_attribute(attribute) %></td>
<% end %>
<td><input type="checkbox" name=send_summary[] id=send-<%= summary.id %> value="<%= summary.id %>" class="send_summary" /></td>
</tr>
<% end %>
</tbody>
</table>
And the email:
<table>
<thead>
<tr>
<% table_view.table_headers.each do | table_header | %>
<th><%= table_header %></th>
<% end %>
</tr>
<tr>
<% summary.attributes.each do |attribute| %>
<td><%= summary.render_attribute(attribute) %></td>
<% end %>
</tr>
</thead>
Note that the replacement looping code is identical between the two views. The difference is in how table_headers and attributes are defined in the Draper decorators that wrap the summary before it’s either 1) displayed to an admin screen or 2) rendered into an client email.
Previously, our decorator was called CallReportSummaryDecorator, the name provided by the decorator generator. My inclination, now that we have two wrappers decorating the same model, is to rename it more appropriately to what it is, i.e. CallReportSummaryAppTableView. And then, to have a corresponding CallReportSummaryEmailTableView.
Since each table header matches up with a piece of data, to me it makes sense to define a hash in each decorator that provides the configuration for each table.
In CallReportSummaryAppTableView:
def column_attribute_map
{
"Clicks" => :total_clicks,
"Calls" => :total_calls,
"Convs" => :total_conversions,
"Cost" => :total_customer_cost,
"Cost/Click" => :average_customer_cpc,
"Cost/Call" => :cost_per_call,
"Click-To-Call" => :calls_per_click,
}
end
In CallReportSummaryEmailTableView:
def column_attribute_map
{
"Total Amount" => :total_customer_cost,
"Impressions" => :total_impressions,
"Clicks" => :total_clicks,
"Cost/Click" => :cost_per_click,
"Calls" => :total_calls,
"Cost/Call" => :cost_per_call,
"Click-to-Contacts" => :calls_per_click,
"Average Position" => :average_pos,
}
end
table_headers and attributes are methods that access that configuration:
def table_headers
column_attribute_map.keys
end
def attributes
column_attribute_map.values
end
The identical implementations of those two methods in the two view classes calls for a refactoring, a superclass, so I create a CallReportSummaryTableView. Those methods can be defined once in that class and inherited. render_attribute is in the same boat, it’s implementation is:
def render_attribute(symbol)
send(symbol)
end
Formatted attributes that are shared between the two views, like :calls_per_click, can be implemented in the superclass view like:
def calls_per_click
h.format_percentage(@model.calls_per_click)
end
Formatted attributes specific to each leaf view class can implemented there.
Note that the Draper gem generates an ApplicationDecorator class where general formatting methods, like format_percentage, can be defined. Using it, it’s likely you could bypass application-specific helpers entirely.
def calls_per_click
format_percentage(@model.calls_per_click)
end
Conclusion
I don’t know if I performed any mind blowing feats here, but I feel good about this. It’s a bit cleaner, and my view code, previously in helpers, has a nice OO home now where I’ve already started to do some refactoring and code- sharing. In the template, I’m able to call display-related methods on the model, which feels more natural than invoking a detached helper method. But I don’t have to implement those display concerns in the model itself, where they don’t belong.
All in all, I’m feeling confident that Draper is a crucial ingredient to good design. This feels less like a gem that provides some functionality, and more like an integral, missing piece of Rails to me.
