I am aware of the existence of helpers. But they are in no way a silver
bullet to building HTML tags. First of all, the number of helper_class()
methods proportionally increment with the number of attributes/class you
use. Soon enough, you get very complicated helper method name due to very
close but yet different methods. This is one of the reason why some people
uses Presenters/Decorators in their project.
On Monday, October 27, 2014 5:12:43 AM UTC-4, Abdelkader Boudih wrote:
>
> :-1: You should be using helpers.
>
>
> <% for @posts.each do |post|%>
> <%= content_tag :li, post.title, class: post_classes(post) %>
> <% end %>
>
> # in PostHelper
> def post_classes(post)
> # your code here
> end
>
> On 27 October 2014 09:02, Anuj Dutta <dutta...@googlemail.com
> <javascript:>> wrote:
>
>> Hello,
>>
>> How about moving the conditional to a helper in your first example? Just
>> curious to know if you would prefer that approach.
>>
>> Thanks.
>>
>> Anuj
>>
>> On 26 Oct 2014 17:34, "Pier-Olivier Thibault" <pot...@gmail.com
>> <javascript:>> wrote:
>> >
>> > Hello everyone,
>> >
>> > I have a feature request here that comes from an internal struggle here
>> between view helpers, decorator patterns and ERB in general. A problem that
>> occurs from time to time is how to build HTML tags with different settings
>> depending on the some states. Here's an example of what I mean.
>> >
>> > <% for @posts.each do |post|%>
>> > <%= content_tag :li, post.title, class: "post #{post.id == 3 ?
>> 'selected' : ''}" %>
>> > <% end %>
>> >
>> > With builtin' methods, there's many way to build this kind of HTML tag.
>> And I'm sure people here knows a few of them. However, none seem to really
>> make it easy to build them. So I decided to take a stab at it this weekend
>> and came up with this solution.
>> >
>> > <% for @posts.each do |post|%>
>> > <%= content_tag :li, class: %w(post) do |li| %>
>> > <% if post.id == 3 %>
>> > <% li.css << 'selected' %>
>> > <% end %>
>> > post.title
>> > <% end %>
>> > <% end %>
>> >
>> > All attributes can be either set inline (as previously possible) or
>> through a tag object that is available inside the block. Now, since this
>> might not be really easy to figure out how useful this could be, I created
>> a helper that overrides content_tag() and saved it as a gist for you to
>> test out locally. It's very possible that there's a few bugs as it's the
>> very first version.
>> >
>> > Gist: https://gist.github.com/pothibo/69d60505fa6e44863e52
>> >
>> > Would this be something RoR:Core would be interested in merging into
>> Rails?
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "Ruby on Rails: Core" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to rubyonrails-co...@googlegroups.com <javascript:>.
>> > To post to this group, send email to rubyonra...@googlegroups.com
>> <javascript:>.
>> > Visit this group at http://groups.google.com/group/rubyonrails-core.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to rubyonrails-co...@googlegroups.com <javascript:>.
>> To post to this group, send email to rubyonra...@googlegroups.com
>> <javascript:>.
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
