Oh, people will think of exceptions.... On Fri, Dec 4, 2009 at 4:07 PM, Jacques Crocker <[email protected]> wrote:
> 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] <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. > > > -- > 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.
