Liquid/Haml

[Joe Fiorini]

I've been thinking a lot over the past couple weeks about what makes a
view engine ideal. The major points I realized are:

1) readability
2) code separation
3) speed
4) auto-escaping

in order of decreasing priority. The thing I _love_ about Haml is how
easy it is to read. It is definitely the best view engine out there
for #1. I haven't noticed any problems with #3 or 4, so that's fine
for me. #2 is where my problem comes in. While Haml definitely
encourages much cleaner code separation than Erb, it's still not
ideal. There is nothing stopping you from ending up with some ugly
chaining scenarios or calling code you probably shouldn't. For this
requirement, Liquid seems to be the best engine (in fact, the view
engine Django uses by default looks exactly like Liquid).

This lead me to a conclusion: a Haml engine that parses Liquid code
instead of Ruby would be the ultimate. I have a very basic prototype
of this working at http://bit.ly/xIuQq. Basically, I override
push_script and push_silent to use Liquid's {{ ... }} and {% ... %}
respectively. Then, in render, before evaling the precompiled source,
I parse it through Liquid. As I said, it's a basic prototype, but I
wanted to start a discussion around this for a couple reasons:

1) To see how many people think like me and may want to use this
and
2) To get some thoughts on better ways to handle hacking Haml. I think
we can do some minor refactoring to make this much easier if the
interest is there.

Thanks all!
Joe Fiorini

[Nathan Weizenbaum]

I'm curious how you envision the refactoring of push_script and push_silent. I'd be happy to modify them for greater extensibility, but I'm not sure exactly what that would look like.