This is actually my point. Helpers are useful when you build a method that
is reusable enough to be used in different places. I didn't write this
because I wanted to get rid of helpers. I still use helpers while using
this new content_tag() method.
My rule of thumbs is as follow:
I start with content_tag, as soon as I can use a helper to wrap different
content_tag under 1 helper method, I'll do it.
I believe that there's a space between inline HTML and helper methods that
this could very well address. As for the tests, well, I don't know how you
tests your helpers but I do test mine by looking at the rendered HTML and
querying it. Same can be done with this method. I highly doubt that you
don't have a single flow condition in your views.
On Monday, October 27, 2014 11:24:04 AM UTC-4, Abdelkader Boudih wrote:
>
> Could you give an example how to test it before burying my argument.
> Also helpers can be reused in other views/partials .
>
> On 27 October 2014 15:19, Pier-Olivier Thibault <pot...@gmail.com
> <javascript:>> wrote:
>
>> This is as testable as any helpers. This argument is moot.
>>
>> On Monday, October 27, 2014 9:58:42 AM UTC-4, Abdelkader Boudih wrote:
>>>
>>> Helpers are testable!
>>> Views should have no complex logic on them.
>>>
>>> On 27 October 2014 11:40, Pier-Olivier Thibault <pot...@gmail.com>
>>> wrote:
>>>
>>>> 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> 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>
>>>>>> 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.
>>>>>> > To post to this group, send email to rubyonra...@googlegroups.com.
>>>>>> > 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.
>>>>>> To post to this group, send email to rubyonra...@googlegroups.com.
>>>>>> 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.
>>>> To post to this group, send email to rubyonra...@googlegroups.com.
>>>> 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.
