Checked it out. Looks great, but several questions in my mind would be:
- I didn’t see any support in the code for block-controlled view constructs
such as:
<% for foo in @foos do %>
<%= foo.name %>
<% end %>
That was a difficult early decision to make. At first, it was something that I planned to add. But, then as we began to use it on our projects (several of them so far) we found that not having if, loops, and blocks is actually a good thing.
Our code ends up being more readable, and it forces us to make hard-but-good decisions on whether the bit of wanted functionality should be a partial, a helper, or a one-line-loop. Generally, this means that the code is far more readable
You’d say this
= print_foo_names(@foos)
and go put that in the helpers.
I.e., how do you stick raw Ruby in without the results being inserted in the
stream?
Well, in general, that code should be in the view, assuming that it doesn’t return a result.
However, if you want a hacky way…
= action_with_no_result && nil
Any line that returns a nil will not print… that’s including tags.
#wontprint= nil
It can be helpful when you want a wrapping div and you’d like to supress the output.
- What is the ~ character for? I saw it in the tests and the plugin code,
but not sure what it does.
Well, the biggest problem with auto-indenting code are those pesky
, , and tags. In all of HTML, they are the only ones who don’t want to be indented or you get wonky results.
I spent more time on this issue than on any other in building HAML. I could fill a book with my thoughts on it and my struggles. However, after talking to some very smart people and doing lots of consideration, this was the result.
First, ~ simply says “hey, watch out, you might be given some whitespace sensitive stuff coming into you from the evaluation on the right”. But, what it does is causes some processing that changes “\n” into the UTF-8 entity for endlines. Basically, it puts the whole tag on one line, but puts in an endline character that the browser can respect, but won’t mess up your output.
It keeps the output beautiful and doesn’t hurt anything. Also, it saves some processing to only have to specify where it might happen.
- How would designers work with this?
Our designer loves it. They don’t really care about HTML, they care about understanding the structure of the page. Also, they go crazy for the CSS style syntax.
Funny story, Anthony, the guy who posted below, he wouldn’t work the other day because we didn’t install haml on a project. He now refuses to work on any projects that don’t use HAML. Simply because he likes the syntax and the way it helps him think about the pages structure. Honestly, I am super surprized by this outcome, but it speaks a lot to what our problems have been so far.
Thanks
Sincerely,
Hampton Catlin.
