Haml + DryML in Hobo ?

[Rhyhann]

Hi,
Haml (http://haml.hamptoncatlin.com) is a very known template system
for Html. It's very used in the Ruby community, particularly in Rails.

I use it as a normal templating language, and it makes me code a lot
faster. I've seen that Dryml also speeds coding up, so what about
mixing them, or at least make Dryml available for Haml coders ?

I posted here, in Hobo-users, since I'm not a developer of Hobo.

[Bryan Larsen]

I'm a fan of Haml as well, but have since switched to DRYML. DRYML is
my favorite part of Hobo, by far.

The major benefit of Haml for me is that it declutters my HTML. If
it actually speeds things up substantially, you're using the wrong
text editor to edit HTML. More accurately, the speedup you get is
tiny compared to the speedup the Hobo+DRYML+Rapid stack gives you.

DRYML stanzas tend to be way smaller than HTML stanzas, so they don't
usually need decluttering as badly.

DRYML won't necessarily save you time up front: It's RAPID, the DRYML
tag library that does most of that. (and it does a lot of that!)
DRYML enables proper HTML subcomponent reuse, so it should provide
significant benefits in consistency and maintenance costs.

The next question becomes: why can't you have the best of both
worlds? DRYML is XML based and HAML can produce XML. If you were
willing to add a "compile" step to your Rails program you could code
your DRYML in HAML and then use the haml command line program to
convert it into DRYML.

If it can be done offline, why can't it be done inline? Certainly
DRYML could be hacked to call haml before doing the XML processing.

A better question is: why doesn't DRYML follow the template standard
that haml, liquid, et cetera use? Then we could mix & match as
desired.

When I asked Tom why DRYML was hooked so deeply into Rails, he gave
these two answers:

1) Hobo was developed before Rails fragment caching. Hobo
desperately needed fragment caching for performance, so he created his
own. Now that Rails has fragment caching, the matching Hobo code
should be ripped out.

2) Everybody other template system produces ruby code that can be
executed via eval. DRYML returns a first class Ruby object. This
let's us do "include" effeciently. Tom being Tom, he has figured out
a way that should let us solve the "include" problem, but it hasn't
been implemented yet.

So right now the main reason DRYML isn't available standalone is
because we haven't had the resources to do so, as well as a component
of "if it's not broken, don't fix it."

cheers,
Bryan

[Tom Locke]

> A better question is: why doesn't DRYML follow the template standard
> that haml, liquid, et cetera use? Then we could mix & match as
> desired.

You should be able to mix and match DRYML with any other template
language in a single app, just not in a single template (e.g. you can
have some DRYML templates and some HAML ones). I doubt you'd want to
though would you? Either way, I don't think the way DRYML integrates
with Rails effects this.

> 1) Hobo was developed before Rails fragment caching. Hobo
> desperately needed fragment caching for performance, so he created his
> own. Now that Rails has fragment caching, the matching Hobo code
> should be ripped out.

Just to clarify: this is compiled template code caching, not fragment
caching.

Cheers

Tom

[Bryan Larsen]

On Apr 20, 8:55 am, Tom Locke <t...@tomlocke.com> wrote:
> > A better question is:  why doesn't DRYML follow the template standard
> > that haml, liquid, et cetera use?  Then we could mix & match as
> > desired.
>
> You should be able to mix and match DRYML with any other template  
> language in a single app, just not in a single template (e.g. you can  
> have some DRYML templates and some HAML ones). I doubt you'd want to  
> though would you?

Yes, that's exactly what I want to do. HAML is a nice XML
representation, so it would be a nice DRYML representation....

cheers,
Bryan

[Tom Locke]

>> You should be able to mix and match DRYML with any other template
>> language in a single app, just not in a single template (e.g. you can
>> have some DRYML templates and some HAML ones). I doubt you'd want to
>> though would you?
>
> Yes, that's exactly what I want to do. HAML is a nice XML
> representation, so it would be a nice DRYML representation....

What I meant was, I doubt you'd want to have a mixture of DRYML
templates and HAML templates in the same app.

A version of DRYML with HAML syntax would be possible, although
personally I dislike HAML syntax.

Tom