Thanks for the feedback Hampton! Gave me some good motivation to work on the patch. Hopefully should have it ready soon.
I totally agree that this patch address be a very limited syntax change. Specifically for multiline argument lists (separated by commas). No special cases that I can think of at the moment. Here's the unit test I'm targeting first (in helpers_test.rb) http://gist.github.com/249103 On Dec 4, 2009, at 1:52 AM, Hampton wrote: > 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]. > > > > 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. > > > > > -- > > 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.
