HAML: RoR's new templating engine

Rails
1

Hampton Catlin is presenting a new template engine called HAML at
RailsConf tomorrow.

It combines structured XHTML creation with inline Ruby, but also
borrows the same language used to define CSS. You have to see it to
know what I mean.

I just learned about the project a couple of days ago, and I think it
has a really bright future. My colleagues and I at Unspace prepared an
introductory article on it here:

 http://unspace.ca/discover/haml/

If you like the article, please help spread the word with a Digg:

http://digg.com/programming/Introducing_a_new_templating_engine_for_Rails

Also feel free to work on the Wikipedia entry:

 http://en.wikipedia.org/wiki/HAML

To hear more you’ll have to see Hampton at RailsConf tomorrow.

John

2

Looks really awesome…

3

On 9/13/06, John Philip G. [email protected] wrote:

Hampton Catlin is presenting a new template engine called HAML at
RailsConf tomorrow.

It combines structured XHTML creation with inline Ruby, but also
borrows the same language used to define CSS. You have to see it to
know what I mean.

Interesting… No offense, I’m sure it’s a good system in its own
right, but I’ve been trying very hard to get away from
whitespace-significant programming recently. :slight_smile:

-Pawel

4

That was one of the first questions I had for Hampton when I saw HAML.
But you can see how the syntax is so much more succinct without it,
because you don’t need closing braces/tags, and then you are not much
better off than using regular XHTML.

5

On Sep 13, 2006, at 3:53 PM, John Philip G. wrote:

introductory article on it here:

 http://en.wikipedia.org/wiki/HAML

To hear more you’ll have to see Hampton at RailsConf tomorrow.

John

This does look very nice. One thing I ran into instantly and that

wasn’t mentioned in the docs was how to do mutli line iterators. Like
when you want to iterate over a collection and output elements. I
couldn’t figure out how that would work. Can you give a clue?

Other then that, way cool. I'll definitely give it a go if it can do

multi line statements.

-Ezra

6

I haven’t used it much at all myself, that’s why the article is so
basic… but from what I understand you would use regular Ruby control
structures.

The best thing to do would be to hear from Hampton himself. If you’ll
be at RailsConf don’t miss his presentation tomorrow.

Also, I’m sure after his presentation there will be a lot of interest
to get HAML documented and so forth.

7

Interesting. It’s nice to have another alternative to rhtml, and I
couldn’t agree more with that page’s statement that we should have
better. I think I’ll still probably stick with Markaby, but there are
some things I think I might like better in HAML, such as no
closers/blocks. I wonder if Rails’ caching works with HAML (it doesn’t
with Markaby so far – been waiting and waiting for why to release a new
version and docs).

Joe

8

Checked it out. Looks great, but several questions in my mind would be:

  1. I didn’t see any support in the code for block-controlled view
    constructs
    such as:

<% for foo in @foos do %>
<%= foo.name %>
<% end %>

I.e., how do you stick raw Ruby in without the results being inserted in
the
stream?

  1. What is the ~ character for? I saw it in the tests and the plugin
    code,
    but not sure what it does.

  2. How would designers work with this?

Thanks

John Philip G. wrote:

has a really bright future. My colleagues and I at Unspace prepared an

 http://en.wikipedia.org/wiki/HAML

To hear more you’ll have to see Hampton at RailsConf tomorrow.

John

–
View this message in context:
http://www.nabble.com/HAML%3A-RoR's-new-templating-engine-tf2268612.html#a6299823
Sent from the RubyOnRails Users forum at Nabble.com.

9

How the hell do you do control structures like loops in HAML???

HAs anyone had any success??

Thanks
CHRIS!

10
  1. How would designers work with this?

Frankly, it’s a godsend :wink:

I am a designer at Unspace and have been working in HAML since Hampton
created it, and I find it much easier to use than traditional markup.
It makes complex, HTML heavy pages very readable and compact. I also
think since class and id names have direct correlation with CSS it just
makes sense if you know what I mean. I picked up HAML pretty much right
away and haven’t looked back.

I think if your designers are comforatble working with CSS/XHTML they
shouldn’t have any problem with it.

  • Anthony Watts
11

On 9/14/06, s.ross [email protected] wrote:

<%= 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.

  1. 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.


3. 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.
12

So, assume you want to make a list.

.ul
= print_foo_names(@foos)

…

def print_foo_names(foos)
foos.each do |foo|
content_tag(‘li’, foos.name)
end

Is this the general idea?

Hampton wrote:

You’d say this

= print_foo_names(@foos)

and go put that in the helpers.

–
View this message in context:
http://www.nabble.com/HAML%3A-RoR's-new-templating-engine-tf2268612.html#a6309570
Sent from the RubyOnRails Users forum at Nabble.com.

13

Hello John,

2006/9/13, John Philip G. [email protected]:

 http://unspace.ca/discover/haml/

That’s a great example. One thing I would have liked to see is a call
to a partial. Is it as simple as:

%table
%tbody
%tr= render(:partial => ‘foo’, :collections => @foos)

Thanks !

François Beausoleil
http://blog.teksol.info/
http://piston.rubyforge.org/

14

Francois B. wrote:

%table
%tbody
%tr= render(:partial => ‘foo’, :collections => @foos)

Looks good to me Francois.

15

You can make helpers… but I’d argue that in your example, you’d want
to use a partial.

Down with code inside views!

16

What I’m grappling with is the case where you have a relatively large
number
of records returned from a query. There are times where

render :partial => ‘foo_partial’, :collection => @foos

works great, but then there are times where custom iteration is more
effective. Do you wrap every conditional piece in a partial, as:

= render :partial => ‘admin_menu’ if admin?

There’s just not a lot of information out there yet.

I wouldn’t be spending so many cycles on this if I didn’t think HAML had
a
lot of potential. There’s just something I’m not seeing…

Ryan McMinn wrote:

–
View this message in context:
http://www.nabble.com/HAML%3A-RoR's-new-templating-engine-tf2268612.html#a6310649
Sent from the RubyOnRails Users forum at Nabble.com.

17

On Sep 14, 2006, at 10:17 AM, s.ross wrote:

= render :partial => ‘admin_menu’ if admin?

There’s just not a lot of information out there yet.

I wouldn’t be spending so many cycles on this if I didn’t think
HAML had a
lot of potential. There’s just something I’m not seeing…

I agree. I think this looks really promising and would love to be

able to use it. unfortunately I don’t think its realistic to now
allow multi line iterations. I may have a look and patch this in
though. Was it left out because it was hard to implement or because
the authors really don’t think its needed? I really like the looks of
these templates but no multi line loops is a show stopper for me.

I mean, what about form_for block? How do you do those? do you have

to render a partial that has normal erb in it? I just don’t think it
makes sense to not allow multi line loops. I would love to see this
added.

Cheers-
-Ezra

18

Not allowing multi-line iterators is a pretty big limb to cut off, but
I’d like to see it explored more before people demand familiarity. I’m
pretty interested in this, and plan to try to contribute some patches
in the coming days. One obvious change I feel is that elements like
img, br, hr and link shouldn’t require explicit closing by the coder.

I am also curious to analyze the source more and see if there’s a good
reason not to use the ActionView tag helper lib for basic tag creation.
It does escaping and the basic task it is charged with pretty well
already. Perhaps the authors could elaborate on why they avoided that?

19

On 14-Sep-06, at 12:18 PM, Francois B. wrote:

That’s a great example. One thing I would have liked to see is a call
to a partial. Is it as simple as:

%table
%tbody
%tr= render(:partial => ‘foo’, :collection => @foos)

Yes. That’s exactly how you’d do it, actually.

/Jeff

20

Steve R. wrote:

What I’m grappling with is the case where you have a relatively large
number
of records returned from a query. There are times where

render :partial => ‘foo_partial’, :collection => @foos

works great, but then there are times where custom iteration is more
effective. Do you wrap every conditional piece in a partial, as:

= render :partial => ‘admin_menu’ if admin?

You can certainly do that line.

There’s just not a lot of information out there yet.

I wouldn’t be spending so many cycles on this if I didn’t think HAML had
a
lot of potential. There’s just something I’m not seeing…

And from your post above: that is indeed the idea. Do you big loops of
simple things in helpers. Exactly as you said above.

Works nice for taking little obscure loops and making them more clear!

-hampton.