Nathan... please read Justin Dossey's post carefully. I believe this
is the negative end result of trying to force this issue via haml
syntax. You end up with workarounds that end up doing the exact
opposite of what was intended in the first place (to reduce ruby code
in the haml template).

On one of my client's project (with half dozen developers), I also see
code very similar to this in much of the haml code (evaluation lines
in the template to build an attribute hash to pass to a helper). This
is much worse than allowing helpers with multiple lines, and just
serves to introduce more ruby code into the template layer.


On Nov 30, 3:44 pm, Jacques Crocker <[email protected]> wrote:
> Totally agree with svoop. Specifying attributes for HTML tag helpers should 
> be just as seamless as specifying attributes for haml elements. I don't see 
> the point in having the haml markup decide that one is better than the other, 
> and making things miserable for the people who use the tag helper approach.
>
> Based on the response so far, I really think there's a fundamental 
> disagreement here that is worth exploring. Why is it "cleaner" and more 
> readable to create a helper just so I can define a long list of attributes to 
> an html helper function.
>
> Here's an example from a project of mine (github.com/merbjedi/alertme_tv)
>
> = form_for @user, :action => "/users/mini_register", :method => :put, :class 
> => "ajax_form", :rel => "#dropmenu_account", :builder => FieldBuilder do
>   .....
>
> If this is used only one place in the project, what possible benefit is there 
> in turning this into a helper? The cost: I'd have to name the helper, add 
> tests for it, then have to worry about wrapping the yield statement. The end 
> result: obfuscating a perfectly readable (though verbose) line of code. And 
> say I later want to change the target of the ajax form. I have to first track 
> it to the template, then track the helper that I created to build the form. 
> All hidden costs that make the code less maintainable for something that is 
> logically nothing more than a wrapper for a <form> tag.
>
> The alternative:
>
> = form_for @user,
>             :action => "/users/mini_register",
>             :method => :put, :class => "ajax_form",
>             :rel => "#dropmenu_account",
>             :builder => FieldBuilder do
>   .....
>
> I think this is slightly better than having it all on one line. And in my 
> opinion, superior to moving it into a helper. But I can assure you this tweak 
> wont all of a sudden force you to stop using helpers within your haml 
> templates.
>
> So all I'm after is an answer to this question: if I go ahead and implement 
> this minor syntax within haml, will it be supported and allowed to be merged 
> into a future release of haml?
>
> Thanks to everyone on the thread so far for the discussion & feedback.
>
> On Nov 26, 2009, at 1:36 AM, svoop wrote:
>
>
>
> > There are those who see helpers as supersemanitc placeholders, others
> > who see helpers as extensions to the HTML markup. Personally, I'm not
> > dogmatic enough to always prefer one of the two. In the latter case
> > what attributes are for HTML are options for the helper.
>
> > Not sure whether the parser could handle this, but why not using the
> > comma as line continuation marker?
>
> > = link_to 'Akzeptieren', accept_registration_path(user),
> >  :class => 'accept button',
> >  :'data-remote' => true,
> >  :'data-method' => :put
>
> > If you're that concerned about abuse, just raise an exception if the
> > first non-whitespace on the followup line is not a colon.
>
> > --
>
> > 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 
> > athttp://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.


Reply via email to