It's not about what is unreadable vs. what is readable, it's about
what is _more_ readable. The syntactic vinegar associated with the
multiline syntax is a great motivator to ask yourself, "Should this
really be in a helper?" If the answer is no, leave it how it is. If
the answer is yes, your code just got better.
I support a large rails project (>50 controllers, >100 models) and the
unpleasant multiline syntax has helped a lot. It's so unpleasant, in
fact, that we don't use it. If I don't want to create a helper
method for one line of code, I break it up. The example below would
start as
= link_to "Favorites <em
class='count_favorites'>#{count_favorites}</em>", "#"+resource(:users,
:favorites), :class => "dropmenu_trigger", :rel =>
"#dropmenu_favorites"
and become 3 lines if not a helper:
- favorites = "Favorites <em class='count_favorites'>#{count_favorites}</em>"
- fave_link_attrs = { :class => 'dropmenu_trigger', :rel =>
'#dropmenu_favorites' }
= link_to favorites, "##{resource(:users, :favorites)}", fave_link_attrs
Find your own style with this, but don't push for a syntax change
immediately, just because this isn't what you're used to.
Justin Dossey
On Tue, Nov 24, 2009 at 8:01 PM, Jacques Crocker <[email protected]> wrote:
> I don't think there's fundamentally anything unreadable about a long helper
> call, with lots of arguments. Even simple html creation helpers encourage
> this since often you'll add lots of attributes to support complex
> unobtrusive behaviors.
> Breaking it up onto separate lines with commas would still be extremely
> readable and understandable. Also, there's a solid precedent already for
> this in HAML (attributes can already do this) so it doesn't break the syntax
> at all.
> Show me a rails project with thousands of helpers for every single long haml
> line and I'll show you one giant unmaintainable mess.
> On Nov 24, 2009, at 7:56 PM, Alexander Wallace wrote:
>
> Not all situations are cut and dry, and I can't claim that I keep every line
> under 80 chars. But I'd try to reduce some of the cruft by abstracting each
> larger argument chunk into a helper, e.g.
> =link_to favorite_title, favorites_path, :class => "dropmenu_trigger", :rel
> => "#dropmenu_favorites"
> The <em> and interpolation is a good place to start cleaning... it can't
> make every link_to statement a one-liner, but the line above is only ~100
> chars (less than some of my uglier link_to statements, which tend to
> encourage lots of arguments)
> Best,
> Alex
>
> On Tue, Nov 24, 2009 at 10:48 PM, Jacques Crocker <[email protected]>
> wrote:
>>
>> It's not always so cut and dry. Should I be creating a new helper for
>> every complicated link_to statement in rails?
>> Here's one I picked out of a random project
>> = link_to "Favorites <em class='count_favorites'>#{count_favorites}</em>",
>> "#"+resource(:users, :favorites), :class => "dropmenu_trigger", :rel =>
>> "#dropmenu_favorites"
>> Why should I force this to be on one line? And why should I create a
>> helper just for a single link_to statement used once on the site?
>> On Nov 24, 2009, at 7:43 PM, Alexander Wallace wrote:
>>
>> This sounds more of an architectural problem than a markup problem.
>> Argument names for your helpers should (probably) be coming from your
>> controllers - e.g. = some_helper_function(@page, @section, @user) ... I'm
>> not sure what the necessity is to split arguments up into separate lines
>> unless they are strangely long (in which case they could just be shortened)
>> or are actually the return statements from other helpers (in which case it
>> would be cleaner to set those values in the controller)...
>> Alex
>>
>> On Tue, Nov 24, 2009 at 10:37 PM, Nathan Weizenbaum <[email protected]>
>> wrote:
>>>
>>> Even in this case, it ends up working better if you factor those out into
>>> individual named helpers. "= get_new_posts_link" is a lot easier to
>>> understand than a long helper with a lot of arguments, even if that's the
>>> only place you use that helper.
>>>
>>> On Tue, Nov 24, 2009 at 7:31 PM, Jacques Crocker <[email protected]>
>>> wrote:
>>>>
>>>> If thats the case, can we at least make it easier to call helpers with
>>>> lots of arguments?
>>>> = some_long_helper_name arg1,
>>>> arg2,
>>>> arg3
>>>>
>>>>
>>>> Comma + newlines are allowed when specifying attribute syntax. We should
>>>> allow it when calling helpers too.
>>>> In a large haml project, I often have helpers just to provide arguments
>>>> to other helpers. Ends up being pretty terrible sometimes
>>>> On Nov 24, 2009, at 5:44 PM, Nathan Weizenbaum wrote:
>>>>
>>>> The Haml multiline syntax is intentionally awkward. It's meant to
>>>> encourage people away from putting large blocks of Ruby in their views, and
>>>> towards moving their code into helpers. This almost always results in nicer
>>>> code and easier-to-read views.
>>>>
>>>> On Tue, Nov 24, 2009 at 10:15 AM, svoop <[email protected]> wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> How about allowing an alternative multiline syntax:
>>>>>
>>>>> http://pastie.org/713107
>>>>>
>>>>> Maybe this is a no go for the parser, though.
>>>>>
>>>>> Cheers, -sven
>>>>>
>>>>> --
>>>>>
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Haml" group.
>>>>> To post to this group, send email to [email protected].
>>>>> To unsubscribe from this group, send email to
>>>>> [email protected].
>>>>> For more options, visit this group at
>>>>> http://groups.google.com/group/haml?hl=en.
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Haml" group.
>>>> To post to this group, send email to [email protected].
>>>> To unsubscribe from this group, send email to
>>>> [email protected].
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/haml?hl=en.
>>>>
>>>>
>>>> --
>>>>
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Haml" group.
>>>> To post to this group, send email to [email protected].
>>>> To unsubscribe from this group, send email to
>>>> [email protected].
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/haml?hl=en.
>>>
>>>
>>> --
>>>
>>> You received this message because you are subscribed to the Google Groups
>>> "Haml" group.
>>> To post to this group, send email to [email protected].
>>> To unsubscribe from this group, send email to
>>> [email protected].
>>> For more options, visit this group at
>>> http://groups.google.com/group/haml?hl=en.
>>
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "Haml" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/haml?hl=en.
>>
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "Haml" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/haml?hl=en.
>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Haml" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/haml?hl=en.
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Haml" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/haml?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Haml" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group at http://groups.google.com/group/haml?hl=en.
