Marnen Laibow-Koser's Profile

html_safe is usually automatic. It's not generally necessary to call it explicitly. See http://yehudakatz.com/2010/02/01/safebuffers-and-rails-3-0/

Actually, none of this is particularly correct. See my comment below regarding a way to do this without mixing JS, HTML, and Ruby.

Also, var foo = '<foo>' is actually the correct XHTML way of representing the JavaScript for var foo = '<foo>' (unless you're inside a CDATA section). The character entities are substituted before the JavaScript is evaluated. HTML, however, accepts < and > within a <script> element (which I didn't realize—I thought they were invalid, but http://validator.w3.org tells me that they are OK).

I like the idea of Gon, but it mixes JavaScript into the generated HTML, and therefore is not advisable to use. The proper way to pass variables from Rails to JS is as follows:

# app/controllers/products_controller.rb
def index
  @products = Product.all
end

/ app/views/products.html.haml
#products= @products.to_json
/ For simple values, you don't need to_json.

// app/assets/stylesheets/application.css.scss
#products { display: none; }

// app/assets/javascripts/products.js
var products = JSON.parse($('#products'));

This way, your HTML output contains only HTML (JSON is simply text data, after all), and your JavaScript files contain only JavaScript. And that's the way it should be for separation of concerns (see also http://stackoverflow.com/a/7987959/109011 and http://stackoverflow.com/a/8819511/109011).

I use both Cells and Draper. They're entirely different.

Update: I finally found a use case for Draper. I had a method that would choose a CSS class name for a particular model. It was too model-specific to put it in a helper, but too presentation-specific to feel good about putting it in the model. A presentation decorator turned out to be a good solution.

I completely agree with you. This breaks MVC and should not be used. A pity, since I like the idea -- just not the execution.

...and looking at the 'cast again, I'm further conflicted. I'd be inclined to put something like avatar_name in its own partial (or even helper), but neither is satisfactory from an OO point of view, as I mentioned already. At the same time, I wouldn't want to put that much HTML generation in the model, I think, and Cells, while very promising, seems to be trying to solve a different problem (though I could well be wrong). Hmm.

Doesn't that logic go in the model?

How is putting something in the decorator any better than putting it right in the model class? The Presenter pattern is designed to abstract display logic from one (or several) model objects whose data model isn't much like the view. That's not what's going on here, as far as I can tell. Looks rather like you're reinventing helpers.

Now, there may be some call for doing that: as you point out, helpers are among the least satisfactory parts of Rails from an OO design perspective. But I tend to think this is not the right solution to that problem.

OTOH, I usually trust you, so I'm interested in hearing more about your rationale here.