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

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

Reply via email to