Draper, Model decorators

[Pascal Rettig]

Hi Everyone,

What's the consensus on using something like Draper
https://github.com/jcasimir/draper for decorating models for view
output?

I like the idea of have in model-specific (and model-namespaced)
transformation for output rather than sticking everything into helpers
or putting code into models that's presentation related. Helpers seem to
end up being dumping grounds for too much model-specific stuff, and
models can easily get full of a bunch of view-related stuff that doesn't
really belong.

How do people solve this problem effectively or is this a problem that
doesn't need solving?

-Pascal

--
Pascal F. Rettig
Cykod.com
Ph #617.398.0513
twitter.com/cykod

[Tom Dyer]

Pascal,

Yes, agree about helper dumping grounds and removing view/presentation
concerns from models. Better to stick with the single responsibility
principle from the SOLID principles for models. I've used Presenters
to deal with this problem, http://goo.gl/o75XR , http://goo.gl/eX8th

These Draper decorators look like Presenters but with only a 1-1
mapping to models? I would like the freedom to use multiple models to
build a resource representation, (html, json, pdf,...), that was
constructed by a Presenter and given to the client/browser.

Haven't tried this yet but, this resource's representation could be
constructed by a Rails 3 ActionController::Responder using a
Presenter/Draper decorator. The Responder would map the mime-type to
the appropriate Presenter and possibly make an instance of this
Presenter available in a view. This would keep the controllers lean,
use the mime-type to determine the resource representation and to
consolidate all the view logic.
.

> --
> You received this message because you are subscribed to the Boston Ruby Group mailing list
> To post to this group, send email to boston-r...@googlegroups.com
> To unsubscribe from this group, send email to boston-rubygro...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/boston-rubygroup
>

--
Tom Dyer

[Pascal Rettig]

Hi Tom,

Thanks, I think that sums it up - presenters with a 1-1 mapping to
models. I feel 1-1 has some benefits though, as using something like
ActivePresenter with two or three models seems a little like an
end-around the single responsibility principle by exposing the full
interface of two models as a single unit. The examples also like to use
the Presenters for all actions taken by a controller, e.g.:

def update
@signup_presenter = SignupPresenter.new(:user => current_user, :account => current_account)

if @signup_presenter.update_attributes(params[:signup_presenter])
redirect_to dashboard_url
else
render :action => "edit"
end
end

Which is really nice in that it combines two models and skips the need to handle validation for each,
but if the Presenter is also responsible for providing the view logic and formatting that seems like it's
doing too much and those should almost be two responsibilities.

I think having ActionController::Responder map mime-types to specific presenters is a really neat idea,
did you mean the responder would just look for the appropriate response-based Decorator/Presenter
(e.g. UserHtmlDecorator and UserJsonDecorator) ?

-Pascal

[Tom Dyer]

Agree that a simple pass thru of all methods to the underlying models
is not good and is an end-around SRP. That's like just combining the
interface of two models into one, not good. Best that the presenter
expose it's own interface, of helper like methods, that would use the
underlying models.

Yes, my ActionController::Responder would create an UserHtmlDecorator
instance in response to a text/html request in the responder's to_html
method and make it available in the view.

I did some work to extend Prawn to generate PDF forms and could use a
UserPdfDecorator to expose the prawn and pdf form DSL in the views
responding to a application/pdf request via the responder's to_pdf
method.