HAML: RoR's new templating engine

[John Philip Green]

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

[skur...@gmail.com]

Looks really awesome..

[Pawel Szymczykowski]

On 9/13/06, John Philip Green <heyjoh...@gmail.com> 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. :)

-Pawel

[Ezra Zygmuntowicz]

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

[John Philip Green]

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.

[John Philip Green]

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.

[Joe Ruby MUDCRAP-CE]

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

--
Posted via http://www.ruby-forum.com/.

[s.ross]

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?

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

3. How would designers work with this?

Thanks

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

[Watts]

> 3. How would designers work with this?

Frankly, it's a godsend ;)

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

[Hampton]

On 9/14/06, s.ross <cwd...@gmail.com> wrote:

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

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.
 

2. 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 <pre>, <code>, and <textarea> 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.

[Chris]

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

HAs anyone had any success??

Thanks
CHRIS!

[Francois Beausoleil]

Hello John,

2006/9/13, John Philip Green <heyjoh...@gmail.com>:
> 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/

[s.ross]

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%27s-new-templating-engine-tf2268612.html#a6309570

[John Philip Green]

Francois Beausoleil wrote:
> %table
> %tbody
> %tr= render(:partial => 'foo', :collections => @foos)

Looks good to me Francois.

[Ryan McMinn]

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

Down with code inside views!

[s.ross]

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

--
View this message in context: http://www.nabble.com/HAML%3A-RoR%27s-new-templating-engine-tf2268612.html#a6310649

[Ezra Zygmuntowicz]

On Sep 14, 2006, at 10:17 AM, s.ross 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?
>
> 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

[Seth Thomas Rasmussen]

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?

[Jeffrey Hardy]

On 14-Sep-06, at 12:18 PM, Francois Beausoleil 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

[Hampton Catlin]

Steve Ross 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.

[Hampton Catlin]

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

Ezra-

Great questions from you guys. I'm really glad that you guys are zooming
right in there with questions I asked myself many, many, many times.

It really comes down to the fact that blocks in views have always been a
red-flag for me as far as quality of code and readability.

The long term approach for the form_for block is to allow its use in the
helpers. So, I might have a helper like this for a form.

def person_form(person)
form_for(person) do |f|
f.text_area(:name)
f.date_select(:birthday)
f.submit_tag
end
end

Then, when I build my page, it might look like this.

signup.haml
-----------------
%p
My site really rocks!
.signup
%p Please fill out the form below to sign up!
#form_area= person_form()
-----------------

Or heck, just write it yourself using the old helpers.

But, that being said, I'm open to suggestions. The no-block rule has
worked out several times very well to produce simple-looking code with
complex rules that gets hidden and broken up in a few ways.

There is the "More than 10 lines a method is bad" school of thought, and
I'm not necissarily disagreeing this way. Why are we ok with 40 line
views??

-hampton.

PS: So, I need to override the form_for to get it working without an ERB
object, since right now its specific to ERB. That's on the todo list.
Patches for that would be fantastic!

[Hampton Catlin]

I forgot one big thing.

I am considering multi-single line support.

That is...

%div= link_to :action => "logoff", |
:id => @user.id, |
:message=> "message" |

Doing the pipes on the end to put together single-evaluated lines.

In theory, if that was implemented, then blocks *could* be possible.
However, I generally want to stay away from that: see the previous
posts.

(Also, form_for would *never* work, since I'm not using erb, without
re-writing. multi-line or not.)

-hampton.

[Joe Ruby MUDCRAP-CE]

Ezra Zygmuntowicz wrote:
> 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.

+1 for me too. I'm not interested in creating partials for each and
every each loop (which would result in my templates really multiplying),
nor putting the loop into a helper which outputs via Ruby not template
markup or rhtml (yuck).

Joe

[s.ross]

It's a paradigm shift all right. For example,

---------hello.haml--------
!!!
%html
%head
%title this is the title
%body
hello world
%ul= render :partial => 'list_item', :collection => @members
-------------------------------

---------_list_item.haml---------
%li= list_item.member_name
-------------------------------

I'm going to have to dig into what this means when you get into pagination
and such. I use blocks for so much stuff in rhtml it would hurt not to have
them. I think elimination of blocks might break the direction Rails is going
but I don't know for sure...

Steve

--
View this message in context: http://www.nabble.com/HAML%3A-RoR%27s-new-templating-engine-tf2268612.html#a6312632

[Hampton Catlin]

> ---------hello.haml--------
> !!!
> %html
> %head
> %title this is the title
> %body
> hello world
> %ul= render :partial => 'list_item', :collection => @members
> -------------------------------
>
> ---------_list_item.haml---------
> %li= list_item.member_name
> -------------------------------

No, that would be bad.

This will be committed soon.

!!!
%html
%head
%title this is the title
%body
hello world

%ul= list_items(@members) &:login
%ul= list_items(@members) { |m| "#{m.last_name}, #{m.first_name}" }

Like I said though, I'm open to suggestions. I just suggest that anyone
reading this... install the plugin, and convert just *one* template. Its
rather easy. Just change the extention and play with it.

Though, I am always open to reconsidering.

-hampton.

[s.ross]

Can you characterize "bad" (as in, "that would be bad")? I'm finding it
pretty easy to convert templates, although I ran up against one that had
a file-column in it that required some messing around:

= @catalog_item = catalog_item;
link_to(image_tag(url_for_file_column("catalog_item", "image", "thumb")),
{:action => 'enlarge', :id => catalog_item}, :popup => ['new window'])

--
View this message in context: http://www.nabble.com/HAML%3A-RoR%27s-new-templating-engine-tf2268612.html#a6316390

[Seth Thomas Rasmussen]

Heads up: run the tabs to spaces command in textmate, even if you are
using soft-tabs. Maybe I misunderstand that term, but it led me to a
while of frustration 'til I realized what was up. Yay whitespace
lovin'.

So, I'm thinking it shouldn't need me to declare which *html* elements
are self-terminating. But we can leave in the option for
self-termination at will, of course. I was also thinking % with no
identifer could be considered as %p.

What about an inline syntax:

% Hi. Um.. I {em really}, {strong really} like you. Okay.

Also, why not use ActionView::Helpers::TagHelper? It already handles
the basic tag creation in a simple way, and does escaping and such.

[Nex3]

I agree with everything Seth pointed out. Why not let any amount of
(non-newline) whitespace denote a new block, rather than only two
spaces?

I'd also like to add my voice to those who feel that adding support for
Ruby blocks would be a good idea. If you also added some character, say
'-', that denoted code that was executed but not used as output, then
you could do something like:

- for foo in @foolist
%h1 foo.name
%p foo.text

[Chris]

OK, i have > 30 controllers, with hundreds of views. Can you imagine
all the work it would requrie to create sub-views for all my control
loops!? I use rails to be speedy and efficient.

It's a pity HAML is doing this, otherwise it could be a massively used
templating system.

[itsterry]

I echo this.

Have started using HAML for a major project, as it is simply beautiful.

However, I'm not going to write a partial for every tiny loop: it would
be madness.

Neither do I want to mess around with generating layout from a helper
object. Isn't that what views are for ?

Although I understand that 'code in views' == bad, surely the
equivalent of "take this collection of things (which were collected
together somewhere else) and show each one like this" is more markup
than code ?

I'm now in the curious position of using HAML for pretty much
everything, and calling in an rhtml partial when I need to pump out a
list. Hardly ideal...

Terry

[Hampton Catlin]

I'm not against using the - to mean "eval but don't print anything".
However, the problem is the way that its all parsed and executed. We
might be able to work something out, but the deal is that each line is
currently evaluated in-itself.

I'm not sold on the idea that this is a good thing and the
implementation would become much more complex.

However, I still haven't seen any arguements on why this is a Good
Thing, beyond forces of habit, and that some rails helpers use it.
Tradition isn't a good arguement.

In the three fairly-complex projects I have done in HAML, besides
breaking habit, I haven't really *needed* blocks. The closest I got was
a pang of rememberance for how i'd do it in rhtml.

I am listening though, and thinking about this very carefully. I'm more
open to arguements about how people have hit certain problems and can't
solve them with nice-looking code... and there aren't any alternate
helpers that could be made to simplify things.

[Hampton Catlin]

> I'm not against using the - to mean "eval but don't print anything".
> However, the problem is the way that its all parsed and executed. We
> might be able to work something out, but the deal is that each line is
> currently evaluated in-itself.
>

I was unclear in my post.

This should mean.. I'm not against the "-" then I start talking about
blocks and how complex implementing them could be.

I really should read my posts over once before I hit the submit button.

[Joe Ruby MUDCRAP-CE]

itsterry wrote:
> Although I understand that 'code in views' == bad, surely the
> equivalent of "take this collection of things (which were collected
> together somewhere else) and show each one like this" is more markup
> than code ?

It's presentation logic, not really "code". Things like:

unless session[:member].nil?
text "Hello #{session[:member].name}!"
end

Joe

[Ezra Zygmuntowicz]

On Sep 15, 2006, at 5:31 AM, Hampton Catlin wrote:

>
> Nex3 wrote:
>> I agree with everything Seth pointed out. Why not let any amount of
>> (non-newline) whitespace denote a new block, rather than only two
>> spaces?
>>
>> I'd also like to add my voice to those who feel that adding
>> support for
>> Ruby blocks would be a good idea. If you also added some
>> character, say
>> '-', that denoted code that was executed but not used as output, then
>> you could do something like:
>>
>> - for foo in @foolist
>> %h1 foo.name
>> %p foo.text
>
> I'm not against using the - to mean "eval but don't print anything".
> However, the problem is the way that its all parsed and executed. We
> might be able to work something out, but the deal is that each line is
> currently evaluated in-itself.

So this seems more like an implementation issue rather then there is
no reason to allow it right? I really like your syntax but I think
you will keep getting pushback until multi line iterations and if
statements are allowed. I looked at the codebase and I don't think
it would be too hard to add a little state to the parse loop to keep
track of multi line statements and eval them accordingly.

>
> I'm not sold on the idea that this is a good thing and the
> implementation would become much more complex.
>
> However, I still haven't seen any arguements on why this is a Good
> Thing, beyond forces of habit, and that some rails helpers use it.
> Tradition isn't a good arguement.

What about <% cache do %> blocks? what about content_for :sidebar
blocks? there are really a ton of useful situations where the blocks
in a view are very important.

Couldn't you do some look ahead when parsing the template? You
already are loading all the lines into memory before processing with
this line:

template.split(/\n/).map do |line|

What about preprocessing the template to combine multi line
statements starting with == into one line statements starting with =
and with the compressed lines separated with ;

so this:

%body
#posts
== @posts.each do |post|
== link_to post.title, :action => 'foo', :id => post
== end

becomes this internally after preprocessing before parsing:

%body
#posts
= @posts.each do |post| ; link_to post.title, :action =>
'foo', :id => post ; end

Some stupid code that does this preprocessing:

buffer = []
seen = false
last = false
template.each_with_index do |line, index|
if line.strip =~ /^==/
unless seen
buffer << line.sub(/==/,'=').chomp
last = index
seen = true
else
buffer[last] << ';'+line.sub('==', '').strip
end
else
seen = false
buffer << line
end
end

And then go into your normal parse loop now that the multi line
statements are compressed to single line statements? I am sure there
is a better way to do it but this seems feasible.

>
> In the three fairly-complex projects I have done in HAML, besides
> breaking habit, I haven't really *needed* blocks. The closest I got
> was
> a pang of rememberance for how i'd do it in rhtml.

Maybe you haven't needed block because you weren't allowed to do
them ;) I think HAML is truly something very cool, I just think it
won't get as much adoption as it should until you allow multi line
statements period.

just my two cents here of course...

Cheers-
-Ezra

[Justin Forder]

Chris wrote:
> OK, i have > 30 controllers, with hundreds of views. Can you imagine
> all the work it would requrie to create sub-views for all my control
> loops!? I use rails to be speedy and efficient.
>
> It's a pity HAML is doing this, otherwise it could be a massively used
> templating system.

I enjoyed Hampton's presentation at RailsConf yesterday, and I've just
read through the whole of this thread.

One thing that strikes me is that Rails has an asymmetry between the use
of files for helpers (where you can put many helpers in one file), and
the use of files for partials (where you have have one file per
partial). I get the impression that in Chris's case this would lead to
an unmanageable mass of tiny files.

Would it be possible for HAML partials to get away from the "one file
per partial" constraint? It would be good to be able to use named
template fragments, defined either in the file that is using them or in
a fragment library file looked up by convention (or explicitly imported).

In programming, it's a good idea to factor out a new method wherever you
can put a meaningful name to a bunch of lines in an existing method. You
wouldn't dream of doing this if every method had to live in its own
file. Shouldn't the same principles apply to templates?

regards

Justin Forder

[itsterry]

> In programming, it's a good idea to factor out a new method wherever you
> can put a meaningful name to a bunch of lines in an existing method. You
> wouldn't dream of doing this if every method had to live in its own
> file. Shouldn't the same principles apply to templates?

Now _that_ is a smart thought !

[John Philip Green]

Justin Forder wrote:
> Would it be possible for HAML partials to get away from the "one file
> per partial" constraint? It would be good to be able to use named
> template fragments, defined either in the file that is using them or in
> a fragment library file looked up by convention (or explicitly imported).

This idea needs further exploration... I like it. The concept reminds
me a bit of XSL templates: you would usually have many per file, but
HAML would of course have a different mechanism for including the
partials.

Here's an example XSL file if you've never seen one:
http://www.brics.dk/~amoeller/XML/xslt-4.1.html

John Philip Green

[Conrad Taylor]

HI, does this new template engine code work well within Dreamweaver?
I have had very good success with RHTML code within DW.

Thanks,

-Conrad

[Long]

I have been following this thread, though not too closely so I may have missed
some of the following points.

1. My first impression is HAML is so "leading edge" that current editors don't
have any support for it yet.

2. Although RHTML isn't "special" or "better" than ASP, JSP and the likes. However,
besides good compatibility, vanilla HTML do not need further processing. In HAML
just about every line needs to be transformed (HAML -> HTML or whatever). This
beg the question of performance. Are there performance issues we should be concerned
about?

3. HAML perhaps may be easily learned but I wonder how well this works in practice.
It is another layer of abstraction web designers/authors will need to deal with. I am not
sure how well HAML will be accepted in their world.

Long

[Hampton]

Justin-

Now, *that's* along with my thinking.

Very soon we will indeed have multi-line statements. I'm going to make
it clear that I think 99% of the loops in views are *crap* and are
against HAML style.

However, I have wanted to be able to say this.

#links
= link_to "signup", |
:action => "go" |
:id => @id |

I think this looks ok and works great for hashs and making stuff look
good by taking one line and making it go on multiple. That being said,
you could do a loop, though, I really don't recommend it most places.

Now, on to what you said! Your point that we need *another* solution
is exactly what I'm thinking about these days. The fact is that
ApplicationHelpers are weird things. They seem to be where you put it
when you don't have any other idea of where it should go.

DHH said something in his talk that really hit me. "When you fix one
thing, you notice how broken something else is!" That's exactly my
opinion. I think that haml's general restraints (Good Thing) just show
the awkwardness of Helpers at the moment. Or whatever it is that we
can think of that might be better.

One of the solutions I'm thinking of are Markaby fragments. I wish I
could have a backup file of markaby fragments that I can call and use
to describe the little bits that I'm now putting in helpers.

I think the views themselves are better now, now is time to turn our
attention towards new, totally crazy, rebellious ideas for helpers and
fragments.

Please email me directly with your thoughts.

hca...@gmail.com

Thanks,
Hampton.

[Hampton]

>
> I have been following this thread, though not too closely so I may have missed
> some of the following points.

I'm happy to clarify them.

>
> 1. My first impression is HAML is so "leading edge" that current editors don't
> have any support for it yet.

yes, wysiwyg editors have absolutely zero support. However, every
designer I know has dropped wysiwyg for a powerful toolkit of
in-browser css editors and etc.

I'd welcome someone to write that, but its not something any of the
designers I know using this require (or have asked for).

> 2. Although RHTML isn't "special" or "better" than ASP, JSP and the likes. However,
> besides good compatibility, vanilla HTML do not need further processing. In HAML
> just about every line needs to be transformed (HAML -> HTML or whatever). This
> beg the question of performance. Are there performance issues we should be concerned
> about?

It is slower. And you are right that it will always be a bit slower.
However, DBs remain the bottleneck in producing a page, not rendering.
While RHTML may be 2% of the render-time for a certain page, HAML is
about 3-4% of the time. That's absolutely acceptable in my mind when
DBs take up 85% and are still the actual slowdowns.

Caching isn't implemented yet, but it will be soon. (Patches welcome!)

> 3. HAML perhaps may be easily learned but I wonder how well this works in practice.
> It is another layer of abstraction web designers/authors will need to deal with. I am not
> sure how well HAML will be accepted in their world.

Every designer that I know that has used it "in the real world" won't
work without it now. They refuse to use anything else. *Not*
coder-designers, just designers.

HAML makes it much easier for a designer to parse in their mind what
is going on because of the syntax and etc. If statements, loops,
blocks, and hand-coded XHTML is probably the worst thing for a
designer to have to deal with. They should only care about
understanding the structure in the DOM.

We at unspace interactive have been using this successfully in all of
our projects over the past 3 months. It wasn't introduced after it was
created. We held it back to give it its paces and to see how it worked
out. There is a reason that we flew across the world to introduce it
at RailsConf Europe. Its because it works in a real-life situation and
produces great code with very little overhead.

Our goal is to deliver value to our clients, and HAML helps us accomplish that.

It works. Period.

-hampton.

PS: Though, we are always improving!!!!! It isn't finished yet. But,
now is the world's chance to make improvements and to make it kick
even more ass than we could do internally.

[s.ross]

I'm going to have to agree on the designer issue. If your designer is using
DreamWeaver or some other WYSIWYG program, they won't like HAML. At least at
first. HAML is more like the underlying document structure. Not every design
requires knowledge of the document structure, but most good designs are
deliberate and are mindful of the document structure. If you design is not
in this category, rhtml still works fine.

One thing that would really help me (and I believe others) understand the
"it works" part of this equation is a non-trivial example of one action that
really does something interesting. Something that really exercises HAML so
we can learn by example.

This might include a form so we can understand why form_for blocks are not
as interesting in the context of HAML. Additionally, please consider Ezra's
comments about joining block statements because I know there are many
instances where I do things like:

<% content_for :sidebar %>
some arbitrary stuff, optionally drawn from instance variables
<% end %>

or even more frequently:

<% content_for :title %>

Thanks for opening this up to the rest of the Rails world.

Hampton wrote:
>
> Every designer that I know that has used it "in the real world" won't
> work without it now. They refuse to use anything else. *Not*
> coder-designers, just designers.
>
> HAML makes it much easier for a designer to parse in their mind what
> is going on because of the syntax and etc. If statements, loops,
> blocks, and hand-coded XHTML is probably the worst thing for a
> designer to have to deal with. They should only care about
> understanding the structure in the DOM.
>

--
View this message in context: http://www.nabble.com/HAML%3A-RoR%27s-new-templating-engine-tf2268612.html#a6342894

[Nex3]

Speaking to the implementation issues of using loops, I've submitted a
patch that allows the following:
- for page in @pages
%h1= page.name
.page
= page.text
- end
This works for all types of blocks. It should be possible to eliminate
the need to manually type "end" as well. So it's not a problem to
implement loops and blocks in HAML... it's just an issue of whether or
not we want them.

Personally, I feel that loops and especially if statements are
neccessary for the language. There are certainly many times when
they're inappropriate, but there are also many times when they're
legitimately useful. In addition, they're an integral part of Ruby;
various methods built into the language and into Rails rely upon
blocks, the ability to key off a boolean, and the like. HAML won't be
able to use any of this if it doesn't support blocks.

[s.ross]

And the patch is ... where?

--
View this message in context: http://www.nabble.com/HAML%3A-RoR%27s-new-templating-engine-tf2268612.html#a6343610

[Joe Ruby MUDCRAP-CE]

Hampton wrote:
> I'm going to make
> it clear that I think 99% of the loops in views are *crap* and are
> against HAML style.

Odd, since many others here disagree, and so many other existing
template languages do as well...

Joe

[Nex3]

@s.ross: Here:
http://dev.hamptoncatlin.com/haml/ticket/16

[s.ross]

I would add that one of the most Rails-esque things to do is just get
something working and then polish it up later. TDD encourages this too.
Here's an example from scaffold:

<% for column in Catalog.content_columns %>
<p>
<%= column.human_name %>: <%=h @catalog.send(column.name) %>
</p>
<% end %>

<%= link_to 'Edit', :action => 'edit', :id => @catalog %> |
<%= link_to 'Back', :action => 'list' %>

Without knowing anything about the underlying model, this view uses loops to
iterate over the members of the content_columns collection twice. Yeah, the
problem can be solved other ways. It probably *will* be solved a different
way in the final implementation. But somethings just getting the CRUD to
work is enough to see whether you're headed in the right direction.

Would this be sooooo evil to include in HAML?

--steve

--
View this message in context: http://www.nabble.com/HAML%3A-RoR%27s-new-templating-engine-tf2268612.html#a6344104

[Seth Thomas Rasmussen]

I feel like the suggestions for how to handle multi-line blocks here
are turning HAML into an ugly beast, should they come to fruition. It
seems to me that there are probably ways to figure out when a
multi-line statement terminates without any explicit help. For
starters, if = is encountered, but no special symbols for subsequent
lines, couldn't you assume the expression continues until the next
special symbol is encountered?

For what it's worth, I can tell you right now that I'd pretty much drop
HAML like a hot potato if it turned into something that required me to
do == or | for every line of a block. That seems very far off the mark
for what HAML promised out of the gates.

[Nex3]

Don't worry, my patch deals with this. All you have to do for a block
is:

- block_magic do |param|
= param.stuff
%p= param.magic

No closing tag or repetitive characters needed.

[s.ross]

I applied this patch and as I noted in Trac, it causes certain breakage in my
code. Maybe I did something wrong...

(eval):3:in `template_eval': compile error
(eval):3: parse error, unexpected '(', expecting $
$HAML_instance << ""( "fine" * 3).to_s << "\n"
^
Extracted source (around line #0):

1: = "fine" * 3

Here's the template that breaks (expected result: finefinefine):

= "fine" * 3

And one that works around the above error:

%p= "fine" * 3

--
View this message in context: http://www.nabble.com/HAML%3A-RoR%27s-new-templating-engine-tf2268612.html#a6346496

[Long]

I am developing a Rails site and am gearing for deployment. The one last
bit I want to do (and need help with) is to make the site more professional
looking.

1. I need a good stylesheet color scheme for font, div borders and background.

2. I am somewhat a minimalist. I only need a handful of graphic icons and
maybe a site logo.

3. The overall site layout is done and set. I may need help with layout for
specific areas within a page.

Work will be off-site. I don't think it will require a lot of work (I could be
wrong) but if you are interested in helping, send me a note to

long755[@]rogers[dot]com.

In the message, describe your background and current work. Please include
links to live sites that you've designed or created graphics for. Note, resumes
will NOT be read.

I want to thank you all for your interest, but only successful candidates will
be contacted for round 2.

Cheers,

Long
PS: If you know of a good designer please forward this message.

[Seth Thomas Rasmussen]

Checking back in.. I lost steam with HAML. Going back to the few
templates I initially converted, I'm not sure I like it as much. I do
want to keep an eye on it, though.

Hampton, you commented on DBs being the bottleneck, not rendering, but
from what I've heard (including from members of Rails core), rendering
has actually been one of the most notorious performance monkeys on our
collective back for most of Rails life thus far.

This is just what I've heard, and I'd be interested for more of your
take on this.

[Long]

My bad. I somehow created a new thread that followed this one...

Back to rendering performance. In a templating system, my understanding
is that static content is usually pushed to the template and one tries to keep
dynamic content to a minimum. Rails has many helpers that are used to transform
to static html, for convenience. This can be good but the cost is performance when
it is over-used. With rhtml developers do have more control and can balance/tune
rendering speed more easily. I don't think the same can be said for HAML.

Long

[David Barri]

> Hampton, you commented on DBs being the bottleneck, not rendering, but
> from what I've heard (including from members of Rails core), rendering
> has actually been one of the most notorious performance monkeys on our
> collective back for most of Rails life thus far.

On my production site (which is currently in closed beta) DB is
consistantly less than %20, and often under %10. I'd have to agree that
rendering is the main bottleneck.

Just a thought...maybe the DB is the bottleneck on all ur sites because
ur using HAML without caching support (which at view level, requires
blocks)....it's possible.

Anyways, I, like most others in this discussion, think HAML has a LOT of
potential and will be a great product once it matures a bit more and
supports caching and blocks with a nice, easy syntax. Until then I won't
be using it, but I will be watching it's development closely. Keep up
the good work ;)

Golly

[David Barri]

[Oops, repost cos I replied to the wrong email...sorry]

Golly

--
Posted via http://www.ruby-forum.com/.

[Joe Ruby MUDCRAP-CE]

Seth Thomas Rasmussen wrote:

> Hampton, you commented on DBs being the bottleneck, not rendering, but
> from what I've heard (including from members of Rails core), rendering
> has actually been one of the most notorious performance monkeys on our
> collective back for most of Rails life thus far.

I've never had performance problems with rendering. DB is the only one
I've had to watch for.

Joe

[Vishnu Gopal]

I've noticed consistent problems with rendering times. DB queries (once memcached) doesn't seem to be an issue. Especially the link helpers and the routes are pretty pathetic when it comes to speed (and even nominally complex routes). I haven't played around with Edge (or REST) but in the last rails stable, rendering is a bottleneck. Stafan Kaes has a template optimizer (and some pointers to route generation) which has helped me a lot.

Vish

[blinking bear]

When you guys say "DB is consistantly less than %20", where do you get that from?

[David Barri]

blinking bear wrote:
> When you guys say "DB is consistantly less than %20", where do you get
> that
> from?

If you look in the log files you can get info on rendering/DB time.
Eg:
Completed in 0.07800 (12 reqs/sec) | Rendering: 0.04700 (60%) | DB:
0.01500 (19%) | 200 OK

[hca...@gmail.com]

I am certain that for your site that must be true. However, that does
also lead me to believe that you aren't doing DB calls that are that
intensive. Doing three joins across tables that you can't really cache,
because its over several servers and is constantly changing. I
generally have DB calls that are about 70% on most of the *major* calls
to server.

As far as speed in HAML goes, there are a couple notes about it. We
have achieved a 20-30% speedup already in the latest version (0.2)

With silent-scripting, I think that rails-caching probably works now,
though I haven't tried it out yet.

And, beyond that, we are currently starting work on building a C
compiler for HAML (and its derivatives also in development). Basically,
in version 0.2, HAML does some compiling before it gets executed. Very
similar to what ERb does. Anyhow, we noticed that we would very likely
be able to move this code into a C library and have it spit out HAML
buffered-ready code very quickly. Adding that into the codebase (might
show up around 0.5) should make us *faster* than ERb.

Though, only time will tell.

Anyhow, I appreciate the feedback on HAML and will take your concerns
on speed to heart and work even more on getting speed-ups. However,
though I am working to improvements, I don't think that speed should
keep anyone from actually using it in production. Yes, it is slower,
but its not so slow that your site would come to a crawl in any real
sense.

All of our sites still feel zippy.

-hampton.

On Oct 1, 9:26 pm, David Barri <rails-mailing-l...@andreas-s.net>
wrote:

> > Hampton, you commented on DBs being the bottleneck, not rendering, but
> > from what I've heard (including from members of Rails core), rendering
> > has actually been one of the most notorious performance monkeys on our

> > collective back for most of Rails life thus far.On my production site (which is currently in closed beta) DB is

> consistantly less than %20, and often under %10. I'd have to agree that
> rendering is the main bottleneck.
>
> Just a thought...maybe the DB is the bottleneck on all ur sites because

> ur usingHAMLwithout caching support (which at view level, requires
> blocks)....it's possible.
>
> Anyways, I, like most others in this discussion, thinkHAMLhas a LOT of

[s.ross]

Just a comment on a C compiler. It seems like optimizing that close
to bare metal will introduce portability issues. In any case, a
different approach would be to introduce an optimizer much as Stephan
Kaes has shown for Erb. The idea is that you do some semantic
evaluation of the code looking for things like loop-invariants,
common sub-expressions, and expensive evaluations that might be
linearized.

I'm still not sure rendering is that big a deal. It's very difficult
to tell where the components divide out, but RailsBench does a pretty
good job of telling you -- is it clear that everyone is suffering
from templating engine overhead? Compiling to C just seems like a big
hammer.

[Hampton]

A native version would most likely be a unix-only Gem that can
optionally be installed to speed up certain string-manipulations
(especially in the pre-compile) stage.

However, also this weekend, I was working on the code-base for the
upcoming 0.3 release and added caching (via pre-compiled buffering) to
the engine. I was able to achieve a 50% speedup. My benchmarks on v.2
that take 0.5 seconds now take 0.22 seconds (results obviously may
vary).

This puts us much closer to where we want to be.

That being said. I agree with you. All of my production apps seem
zippy enough. I really don't notice any slow-downs at all. However,
that being said, I still think its important to really work on this
and keep the code as stable and fast as possible.

-hampton.