It's not just syntactic vinegar, it makes things extremely hard to change.
Editing every line of the helper with the pipe syntax makes you have to
rebalance the pipes. Also, not a huge syntax change. HAML used to be of the
same opinion on attributes, yet this changed to allow multiline via commas. My
argument could just as easily be about consistency.
Should also mention I've also been using HAML as my primary templating language
for almost 2 years.
On Nov 24, 2009, at 8:22 PM, Justin Dossey wrote:
> 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.
>
>
--
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.
