#286 Draper

It's about time you got some financial reward for all your hard work.

I have an issue about this episode though. Surely the logic that is being placed in the decorator belongs in the model?

I see things like if there is no uploaded avatar then provide a default avatar as business logic and default values provided by the model can be used for xml, json responses, rake tasks etc...
I feel this approach goes against the grain and I feel that this sort of approach is a solution to a deeper problem which is that not enough developers know where to put their logic.

In other words I can't help thinking that this seems to be fixing symptoms of bad coding rather than providing a solution to the cause. We have models, why not use them?

Any reason you chose Draper over Cells which has 116 votes? They appear to address the same issues.

Wow, so this is the best day of my OSS-writing life.

Kevin: Cells is a much bigger idea than Draper. Draper's decorators are forcing Ruby objects into the existing view layer. Cells are almost self-contained MVC systems.

JamesW: Models are about data and business logic, not presentation. In your example, deciding on the default avatar is a presentation issue, not really business logic. For XML or JSON it would be more logical to return an empty string from the default avatar, rather than referencing an irrelevant image.

Joel: I still need to work on the CanCan-compatibility, sorry I haven't had much OSS time lately. If Ryan has any suggestions I'll jump to implement them.

Sounds neat, but all the examples look like a single resource. What about more complex examples; such as a User has_many Posts... In the view one might have a @user.posts.each |post| do ... how do you get a decorator object for those?

Thanks Ryan (and Jeff!)

Just a small question: when refactoring a view, how to choose between using a partial, or using a decorator?

Ryan,

Great episode as always. I had a question about this line:

h.content_tag :span, "None given", class: "none"

What is the difference between :span (which I know is a symbol) and class:? Why is the colon after class?

I'm curious: why the preference for h.content_tag, instead of a little snippet of HTML ?? Is there a reason, aside from aesthetics?

Caution: When using decorators, all your routes are accessibles when prefixed with the h method.

PressReleaseDecotator.rb
h.press_release_path(model)

But if you set default url options in your ApplicationController, they will not be apply. In my case, it's the locale setting...

ApplicationController.rb
def default_url_options(options={})
{:locale => I18n.locale}
end

Thanks for another great episode Ryan!

What would your thoughts on using decorators to show/hide certain information based on the current user's permissions (eg. with CanCan) - by doing something like:

if can? :read, model
  h.link_to model.email, "mailto:#{model.email}"
else
  content_tag :p, "Not listed", :class => "none"
end

within the decorator? A use case might be a member directory where non-members can only see members name but logged-in members can see each others email addresses.

Maybe it's a bit of an edge case? Do you think it would appropriate to put authorisation logic in a decorator?

Glad to see this - we've started using Draper at Tribesports recently, and we're really happy with it. We wrote a couple of blog posts on how it can help implement a clean, versioned API, if anyone's interested:

Part 1 - Versioning the Tribesports API
Part 2 - Separating API logic with decorators

We're actually using it in combination with Cells (mentioned above); we think they're highly complementary. Our site makes heavy use of small resource-specific elements repeated in multiple contexts. Cells lets us pick out the resources we're displaying in a structured manner (cleaning up our controllers), and draper handles the decoration, cleaning up the views.

Thanks for the great episode!

I have a question. If my user model has_one appointment model, both of which have decorators declared, is there a way to call the decorator for appointment from the user? like user.appointment.avatar ? or maybe user.appointmentDecorator.avatar ?

Thanks Ryan !!
The discussions in comments are also very informative, can't we just have a like options there for comments. Most of the times, it happens i don't have something to say, but just liked answers.

@ryan how about using draper with gems like decent exposure. The easy way would be something like

expose(:user) { UserDecorator.find(params[:id])

how about a modified episode that show how by default to use decent exposure and Decorators.

Love the screen cast, they are my weekly dose of something awesome in the rails world.

Why not use the presence method to make the avatar_name method a 1-liner?

def avatar_name
  model.avatar_image_name.presence || 'default.png'
end

Very nice. I've been wanting to get rid of helpers in our application for a quite a while and this looks like a very clean and elegant solution.

i like the idea, but if i start refactoring with a decorator i come across one big problem.

if i wanna wrap a small method to a decorator like user.full_name i would have to make tons of decorators to wrap all my associations, like note.user.full_name, project.owner.full_name etc. well maybe its just realy for big view stuff. but i would love to use it also for the small parts.

+ cancan not liking it :)

Hey guys. Delighted there's now more Railscasts loveliness each week. Yay.

I'm a little confused about what to do with application wide presenters. For example, I want to show either a "Sign In" link or a "Log Out" link depending on whether the user's logged in. This is somewhere I would normally include some logic in the view, probably the app layout and it'd be great to move it to a presenter. But which one?

I'm playing with Sorcery following your recent episode, so I have a current_user object I can inspect to determine whether anybody's logged in. But it's not referenced through a model so I don't know how to move it to a decorator. I could decorate the user model but creating an @user instance in every view feels, well, odd.

Any guidance would be gratefully received.

What's the best way to test a decorator? More specifically, how would you test the following method (in rspec):

def amount
  h.number_to_currency(model.amount)
end

When I try the following, I get undefined method 'number_to_currency' for nil:NilClass:

it "returns the formatted amount" do
  item = Item.create!(:amount => 5.5)
  decorator = ItemDecorator.new(item)
  decorator.amount.should == "$5.50"
end

There's must be some magic going on that sets the view context somewhere. Anyone write decorator helpers for rspec yet?

What if instead of displaying "None Give" for missing fields you wanted to not render the field. That would mean something like

<dt>Twitter:</dt>
<dd><%= @user.twitter %></dd>

would have to become

<% if @user.twitter %>
    <dt>Twitter:</dt>
    <dd><%= @user.twitter %></dd>
<% end %>

or just

<%= @user.twitter %>

and have the presenter output the container markup, which I don't really like. Wondering if there was any cleaner way to do that? Thanks!

is it possible to decoreate current_user ?

I am sure I am just not getting it, but it seems that decorators are just sweeping dirt under the rug. Every time I see changes like this that alter the way apps are written by making them more complex in the name of cleanliness, I feel that it is just one more thing that stands between me and delivering a product to my clients that can be handed off to other developers easily.

I think Jeff is a great guy.. We hung out in Salt Lake City way back and I realized the guy knows his stuff.. This is why I don't want to discount the idea in my head, but are we trying to solve a problem that might not need to be solved? And in turn, are we making it more complex?

I tend to store attributes like status or role as underscored strings (a string that would be
suitable for a method/variable name) sometimes a simple .humanize will do the trick when
it comes to displaying that value in the UI user but other times you need to customize
them a bit which is one reason I18n is great

Here's my ApplicationDecorator which helps automate the usage of I18n for
such a purpose.

https://gist.github.com/1338134

What's the most elegant way to use draper in common with the ancestry gem from episode #262? How do I get all children and parents easily decorated?

The generator for creating decorators is now called just decorator. Thus, use rails g decorator user in place of rails g draper:decorator user

I'm using draper and in my controller's index action, i have following code

@posts = PostDecorator.approved.order('created_at DESC').includes(:user, :category).page(params[:page]).per(5)

and in my view

<ul>
    <%= render @posts %>
</ul>
<%= paginate @posts %>

and I have a partial, _post.html.erb
I want to access methods defined in PostDecorator and UserDecorator in my partial
like post.post_title

What should i need to do to pass @posts variable into my _post partial and access decorator methods

I tried following but failed
<%= render @posts, locals: { post: @posts} %>
and
<%= render @posts, object: @posts %>

Please help me
Thanks :)

Since I've started using Draper, I've generally been pretty happy with it. The one thing that keeps biting me is object equality (decorated_object != object) and in general code that expects to be dealing with an actual instance of the model class and not an instance of the decorator behaves differently or incorrectly when your object isn't actually an instance of your model class.

If @user is a UserDecorator object and current_user is a User object, for example, then even a simple test like this:

if @user == current_user
  ...
end

doesn't work as expected.

Have also had some occasional odd behavior when working with CanCan. (To get error messages to work as expected, for example I had to add a section for user_decorator: in addition to user: in my locale file because it looks up messages based on the object's class.)

I wish Draper worked by mixing in a module instead of creating a an entirely new class. Then a decorated User object, for example, would still be a User and object equality would work as expected.

But I guess Draper was only intended to be used in the view layer, so my mistake was probably that I am decorating objects in the controller as soon as I fetch them from the database. Maybe I will try to only create and use the decorated objects in the view and see if that works any better...

Code is upgraded to Rails 4.2.4 and latest draper version : https://github.com/bparanj/draper