I also think there should be a non-awkward way for multi-line code in
haml. Having consecutive lines of ruby doesn't necessarily indicate
bad readability or maintainability. Especially because in ruby, the
same amount of code can be more readable when written on multiple
lines, such as the helper calls in other peoples' posts.
I think it would be more consistent with the existing HAML syntax, if
- and = could just contain "children" with indentation. For example,
=
link_to(arg1,
arg2,
...)
This is similar to how a regular html element can have indented child
in HAML. The child begins if the next line is indented deeper and ends
when indentation is back to the level of = or -. The whole child would
be evaluated as ruby, lines inside it can have "free" indentation to
line up arguments or not, as long as they are deeper than = or -.
On Nov 30, 7:10 pm, Jacques Crocker <[email protected]> wrote:
> 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.
