First as you read Rails and learn more you will discover the DRY (Don’t Repeat Yourself) principle. This means do something once and then don’t dig another ditch.
So here’s my opinion, both partials and tags are for DRY.
One usage difference in my opion: Is if the output is only a few lines, then a tag is simpler and cleaner. However, if the output is many, many lines of HTML like a menu then I start to lean toward partial. However,
There is one thing that a tag can do nicely that partials can’t as cleanly. Arguments can be passed and code run away from the view. Example:
<%= commentor_pretty_name(blog.login_id) %>
here is the actual tag in application_helper.rb:
##############################
# takes a login_id alone and converts to pretty name for comment/tag
##############################
def commentor_pretty_name(login_id)
def_return = "Nil Name"
begin
logger.debug("app helper commenter_pretty_name")
#the "||" operand below means that we will use the def_return of "Nil Name" if Login.find returns nil Login.find(login_id).unique_name || def_return #end rescue def_return end end
#### END CODE
To do the same in a partial you would have to have this:
<%= render :partial => 'commenter', :locals => { :login_id => user.id} %>
user.id would be passed as argument AND then on the partial you would need some of the ruby code in the actual partial to lookup the user.
<% #note no '=' tag this is purely to run ruby code and set variables
@def_return = "Nil Name"
begin
logger.debug("app helper commenter_pretty_name")
@def_return = Login.find(login_id).unique_name
#end
rescue
@def_return
end
%>
<%= @def_return %>
Best of both worlds? Use a tag to run the ruby code and then a partial to render? When the tag gets riddled with html/view then this presents a good blend of keeping view and model seperate by using a tag to setup/do ruby work and simple partial to present.
