#287 Presenters from Scratch pro

any reason you're using a base class instead of a module, for the base presenter? i'm still pretty early in my rails career (~1yr), but I thought "the rails way" was to use modules instead of inheritance.

Guess you need to change the copyright notice at http://railscasts.com/about .

The purpose of the 'pro' accounts would be defeated by the present Copyright statement :)

Ryan,

This is fantastic, glad to see you'll be making some more money for all your hard work. I'm very happy to go pro. Quick question though, I was very excited to see how you handled your payment, subscriptions, etc. by looking at this app on github. But for some reason, it doesn't look like it's updated there. I see no routes, controllers, models, engines, or anything that builds the subscription/payment parts. How are you handling this/can we view this code?

can you explain what is Presenters ?

Awesome screencast. I love the from scratch episodes and I also enjoyed the inclusion of Test::Unit.

I don't like coupling the name of the model to the name of the presenter. What if you have multiple ways of displaying users, or if you more than one user-like objects?

A simple solution might be something like:

<% present @admin, with: ProfilePresenter do |presenter| %>
   <p><%= presenter.website %></p>
<% end %>

Please correct me if I'm mistaken, but shouldn't your present definition in the ApplicationController look like this?

def present(object, klass = nil)
  klass ||= "#{object.class}Presenter".constantize
  klass.new(object, view_context)
end

The object comes before the template in the initialize method of the BasePresenter.

Awesome information. Glad I subscribed =]

My only question might be a little out of scope for this episode, but how would one go about adding a blank presenter file for inclusion when scaffold is run?

Hi, question. I'm using rspec, and added the 'include ActionView::TestCase::Behavior' as you recommended. However, I'm getting a "undefined method 'setup'" error from action_controller/test_case.rb:12. I am using Rails 3.1.

Any thoughts on what I'm doing wrong?

Suggestion: where you've got Types, "Free Episodes" and "Pro Episodes" in the right hand navigation, how about a "Both Types" option?

Ryan,
I am so pleased that you have decided to offer more screencasts. Thanks for all your great work, you have passed on an incredible amount of knowledge over the years through these screencasts.

• Francois

Is it me or is there any issues with the audio?

Great tutorial, as always! Quick question however. How can we use this technique for local objects inside partials?

We have a partial with a local variable called user (not @user). when trying to apply the same logic to it, i get back the following error 500:

ActionView::Template::Error (undefined method `to_presenter' for #<User:0x10b80f0a0>):
    1: - present user do |user_presenter|
    2:   #contact_information
    3:     %dl
    4:       %dt Name

By the way, there's a small typo in the user_presenter.rb file:

delegate :username, to: :user

should be

delegate :username, :to => :user

This is the best of both worlds. Free RailsCasts to get you going and Pro to push you further. I am waiting for your previous screen-casts to be brought up to date. There is a wealth of knowledge there already.

Keep them coming and congratulations on expanding on what you are already very good at. Can we expect you to respond more actively on the "Pro" screen-cast questions though? Since these are more in-depth, naturally there are more questions.
Bharat

So this screencast is just creating draper library...? :)

ActionView::TestCase::Behavior does not exists in Rails 2.3.x. Does anyone know how to test the presenter within a Rails 2.3.14 app and RSpec 1.3.2?

Ryan, I am a big fan of your Railscasts and I congratulate on Railscasts Pro. However, for a "pro" edition, I found the cast very short and basic. In the cast you assumed that the view only gets one value set (presents). What if the view needs more information, e.g. the controller did that:

def index
@customers = Customers.all
@prices = Prices.all
...
end

How would you do that?

And the second thing is that you just scratched the testing issue. I believe that Presenters shine most in testing.

Maybe I am setting the expectations too high, but I expected a much more detailed (paid) cast.

My 2 cents, good luck with Railscast Pro.

Nifty stuff! I agree that the controller shouldn't need to know about what is basically a super-helper for the view. I've been trying to think if there's any way to pull the "present" helper method out so that it's seamless to the view as well that it's using a presenter.

Possibly a super smart layout? Any ideas?

Hey Ryan,

how about extracting this into its own gem! ;)

Are you going to include specs (and tests) in all the updates to old screencasts? That would be a huge incentive to me to subscribe.

(And thanks for not using only PayPal. Limiting payment to PayPal would be a big *dis*incentive to me.)

Wouldn't it be better that these comments would only be shown to the subscribers?

i would suggest to you make a new video or expand current code sample to show how test/spec the views after apply a presenter on it.
I think it is missing to be full complete episode.
Thanks for you great work!

Ryan, thank you very much for this great episode. I created a gem using your approach on presenters. Check it out: exhibit.

I'm curious why you don't feel the controller should know about Presenters? It seems to me the one thing controllers and presenters have in common, is they both have knowledge of both the model and the view.

I need to look more into the subtle differences between presenters and decorators... maybe understanding that will help me understand why you think the presenters should be instantiated in the view.

Is it very different from https://github.com/jamesgolick/active_presenter ?

Suggested refactor:

module ApplicationHelper
  def present(object, presenter = "#{object.class}Presenter".constantize.new )
    yield presenter if block_given?
    presenter
  end
end

It's better to pass an instance as a parameter than a class

<% present @user, UserPresenter.new do %>

  <!--- stuff --> 

<% end %>

<!-- or -->

<% present @user do %>

  <!--- stuff --> 

<% end %>

Hey Ryan!

It was great episode. Just one think I really didn't like was defining presents method in base presenter. It could be something optional to use but in most cases we have 1-1 relation which can be expressed in BasePresenter in following way:

  def self.inherited(klass)
    name = klass.name.match(/(\w+)Presenter/).captures.first.underscore
    define_method(name) { @object }
  end

what do you think?

How would using HAML change the presenter implementation?

Any suggestions on how to write a presenter for a collection of object, like for an index view?

It is much cleaner, but we can take it a little further. If we change the present method to:

def present(object, klass = nil, &block)
  klass ||= "#{object.class}Presenter".constantize
  presenter = klass.new(object, self)
  if block_given?
    block.arity > 0 ? yield(presenter) : presenter.instance_eval(&block)
  end
  presenter
end

We can slim our view down to:

<% present @user do %>
  <div id="profile">
    <%= avatar %>
    <h1><%= linked_name %></h1>
    <dl>
      <dt>Username:</dt>
      <dd><%= username %></dd>
      ...
<% end %>

We'll still have access to the template via h, just need to make it a public method.

Heh. I'm glad you still have the source on github for pro. That hande_none was driving me bonkers...

After watching the video, I'm slightly confused. It seems that presenters more or less add another layer of complexity to the view concept. Is there some convention that if your controller and view are below a certain complexity level that a presenter isn't a best choice? When would I want to use a presenter vs leaving the show action with a little more data in it?

Also, are presenters main-stream or becoming main-stream? I've heard little about them until recently. Are they something that will most likely stick and become a standard convention?

Looks like something worth learning more about, but not sure I'm fully convinced they are very useful, but that's probably just my lack of experience with them speaking.

So I am implementing this and I am slightly confused as the best way to access the presenter from the layout.

The reason I would like to do this is for menu building.

Has anyone else dealt with this?

Would love to see a follow up RailsCast or a Github example app that has built a Presenter for a Report or Dashboard. That is to say, a Presenter that incorporates data from several models into a single view.

Shouldn't this line:

klass ||= "{object.class}Presenter".constantize

be

klass ||= "#{object.class}Presenter".constantize

?

Hi, just wanted thank you for a great episode, and point out that the ASCII cast states that I should use view_content rather than view_context. Took me a while to figure that out =)

Thanks.

Hey Ryan,

Is there any reason not to have the method missing check the @object first? As the presenters are usual about a particular model, and delegating a dozen items can be painful.

Something like:

 def method_missing(*args, &block)
    if @object.respond_to? *args[0]
      @object.send *args, &block
    else
      @template.send *args, &block
    end
  end

Thanks for the great episode!

is there a way to delegate all instance variables of @template? for example, @controller, @action and others are not set within the scope of the presenter

I've got a solution but would like to have something better

def initialize(object, template)
  @object = object
  @template = template
  @template.instance_variables.each do |var|
    instance_variable_set var, @template.instance_variable_get(var)
  end
end

When writing a presenter from scratch, what is the best way to access the rails helpers? Inside the class I'd have a @context variable which would be used to call the view helpers,

e.g. @context.link_to "help"...

I recently found that when using the method_missing trick in my base presenter class, it raises an exception when I try to use the capture method directly.

Dumb example:

class UserPresenter < BasePresenter
  def some_div(&block)
    content = capture(&block)
    content_tag(:div, content)
  end
end

This raises ArgumentError: wrong number of arguments (0 for 1)

From what I can tell, the reason is because it conflicts with Kernel::capture, maybe because Kernel always have precedence, or something.

In any case, I added a hard capture method to my base presenter class, to work around the issue:

  def capture(*args)
    @template.capture *args
  end

Is there an elegant way to deal with optionally-passed locals?

For example say I call

<%= render 'posts/post', post: post, :size => :panel %>

How can I access that size value in the presenter?

One way is to pass the value into the presenter. For example, from the partial, I might write

<%= post_presenter.some_method(size) %>

But since size is an optional value passed to the partial, it might not exist, and thus would raise an exception when trying to call some_method. You could check if the local variable exists like this:

<% if defined?(size) %>
  post_presenter.some_method(size)
<% else %>
  # Don't call presenter method at all, or do other logic.
<% end %>

However, this is ugly, and defeats the point of the presenter! This is the code that we're trying to avoid in the first place.

Thoughts?

Can I use presenters to clean up a view that does not have a corresponding model (e.g. my Home page, static_pages#home)? If so, how would I set up the presenter class? Thanks!

thank