Doing this much Android programming over the week has melted my brain into liking multi-line arguement strings.
I've always fought against endless "multilines". But, I think there are lots of cases that this won't support... and one that it will... which is having lots of arguments. I DO think in the examples, that you should do something about those link_to's. There is always an abstraction in behaviour. At least, I've rarely found a time when there isn't one. However, even a good helper might need several arguments. So.... (drum roll please)... Hampton Catlin doesn't hate the idea of multilines that *only* apply to method calls with commas between the arguements. *NO* String concatenation on multiple lines *NO* Static single-line HTML information going multiline (make sense?) *NO* Whatever people will think of when they go "weeeeee!" A good language should be readable online. However, a well indented arguement list as we saw in the example is very clearly a single element visually... and is therefore OK semantically/syntactically/usably. -hampton. On Fri, Dec 4, 2009 at 12:55 AM, Yaohan Chen <[email protected]> wrote: > 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] <haml%[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] <haml%[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.
