干燥轨道视图:部分视图与辅助视图
我需要有关干燥视图代码的最佳实践的建议。 我的应用程序中有三个类(NewsItem、RssItem 和 BlogItem),它们使用单独的视图,但其中有类似的部分。其中一个部分是这样的:
<% if current_user %>
<footer>
<%= marks_bar(@item) %>
<%= favorite_button(@item, "blog_item") || delete_from_favorite_button(@item, "blog_item") %>
<%= share_button(@item) %>
<% if current_user.is_mine?(@item) %>
<div><%= link_to "Edit", edit_user_blog_item_path(current_user, @item) %></div>
<% end %>
</footer>
<% end %>
对于所有三个类来说几乎是相等的,所以我决定把它拿出来到某个单独的地方。在这里我很困惑:我应该使用部分方法还是辅助方法? 我知道助手主要用于将 ruby 代码与 HTML 分离,但在这种情况下,助手将如下所示:
def toolbar_for(item, type_str, edit_path)
if current_user
content_tag(:footer) do |b|
marks_bar(item).to_s <<
(delete_from_favorite_button(item, type_str) || favorite_button(@item, type_str)).to_s <<
share_button(@item).to_s <<
(content_tag(:div) { link_to("Edit", edit_path)} if current_user.is_mine?(@item)).to_s
end
end
end
所以,这里几乎没有 HTML 代码。
您能给我建议吗?您认为哪种方法更好?为什么?另外,这些方法是否存在一些性能问题(例如多个字符串串联或频繁的部分加载可能成本高昂)? (这个应用程序负载相当高)
I need an advice on best practices for DRYing view code.
I have three classes (NewsItem, RssItem and BlogItem) in my app, that use separate views, but have similar parts in them. One of the parts is such:
<% if current_user %>
<footer>
<%= marks_bar(@item) %>
<%= favorite_button(@item, "blog_item") || delete_from_favorite_button(@item, "blog_item") %>
<%= share_button(@item) %>
<% if current_user.is_mine?(@item) %>
<div><%= link_to "Edit", edit_user_blog_item_path(current_user, @item) %></div>
<% end %>
</footer>
<% end %>
It's almost equal for all three classes, so I decided to take it out to some separate place. And here I am confused: should I use a partial or helper method for it?
I know that helpers are used mostly for separating ruby code from HTML, but in this case the helper will look like:
def toolbar_for(item, type_str, edit_path)
if current_user
content_tag(:footer) do |b|
marks_bar(item).to_s <<
(delete_from_favorite_button(item, type_str) || favorite_button(@item, type_str)).to_s <<
share_button(@item).to_s <<
(content_tag(:div) { link_to("Edit", edit_path)} if current_user.is_mine?(@item)).to_s
end
end
end
So, there is almost no HTML code here.
Could you please give me advice, what method is better in your opinion and why? Also, are there some performance issues in these methods (for example multiple String concatenation or frequent partial loading might be costly)? (This app is rather high-loaded)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我想说这是局部的一个很好的例子。
我保留了用于生成任意动态内容的助手。这是一个松散的描述,那么举一个例子吧:我将创建一个助手,它将 ActiveRecord 对象数组拆分并将它们显示为 N 列。在这种情况下,正在以某种方式利用传递的对象的结构来生成内容,但内容本身并不重要。如果你仔细想想,form_for也符合这个描述。
相反,部分内容非常适合需要在多个页面上重用的“静态”内容。例如,您将创建一个部分来渲染单个项目。部分确定特定项目的“静态”表示。
在我看来,你的例子更适合第二个垃圾箱。由于
@item
没有被操作来生成内容,因此实际上它几乎没有被使用。看来这个助手主要是其他适当创建的助手(share_button
和marks_bar
)的粘合代码。部分的完美用例!I would say this is a great example of a partial.
I reserve helpers for generating arbitrary dynamic content. This is kind of a loose description so how about an example: I would make a helper that splits an array of ActiveRecord objects and displays them into N columns. In this case the passed object's structure is being leveraged in some way in order to generate the content, but the content itself is unimportant. If you think about it, form_for also fits this description.
Conversely partials are great for 'static' content, that needs to be reused on multiple pages. For instance you would create a partial to render a single item. The partial determines a particular items 'static' representation.
Your example fits much better into the second bin, in my opinion. Since the
@item
isn't being manipulated to generate the content, in fact it is hardly being used. It seems this helper is mostly glue code for other appropriately created helpers (share_button
andmarks_bar
). The perfect use case for a partial!我会为此使用视图部分。好的经验法则:如果输出为 HTML,请使用部分内容。助手不是 Rails 应用程序的垃圾抽屉——它们真正应该用于输出数据,而不是表示。尽管我通常建议人们避开一般的帮助者,而选择演示者,而演示者在 Rails 世界中并未得到充分利用。
I'd use a view partial for this. Good rule of thumb: if HTML is the output, use a partial. Helpers are not the junk drawer of your Rails app—they should really be used to output data, not presentation. Though I usually recommend people eschew helpers in general, in favor of presenters, which are vastly underutilized in the Rails world.