http://jakarta.apache.org/tapestry
to see a really nice happy medium. It uses a templating language similar to TAL but much more flexible (and useful, in my mind) than rigid XML. All its templates can be used in things like Dreamweaver and GoLive with getting munged. I also think that forcing templates to be valid XML is a huge pain in the nuts and would drive most poor HTML monkeys crazy. We're the developers, leave the XML to us... don't force it on people who use photoshop for a living and have learned HTML so they could be a "web designer" because it's just gonna confuse them.
And besides, we're perl developers... we should take one look at XML and vomit at its disgusting syntax and unwieldy markup-heavy, text-heavy guts. You can't beat pure perl for representing data structures, or NeXT plists, for that matter. What's easier, this:
{
XML => "Sucks",
Perl => [
"Rules",
"Is Great",
"Is fun",
],
}or this piece of nastiness
<?xml some crazy required tagged bs?>
<SomeUselessWrapper>
<XML>Sucks</XML>
<Perl>
<UselessItemTag>Rules</UselessItemTag>
<UselessItemTag>Is Great</UselessItemTag>
<UselessItemTag>Is fun</UselessItemTag>
</Perl>
</SomeUselessWrapper>Ok, so I'm not being totally fair, but you get the idea.
XML is a nice idea for certain things but I gotta agree with Andy... keep it out of my web templates.
Cheers
Kyle Dawkins Central Park Software
On Monday, Jul 28, 2003, at 12:27 US/Pacific, Jean-Michel Hiver wrote:
If you like a more straightforward approach, TT also lets you write:
<div dir="$language_dir"> $some_content </div>
See, I knew there would be something that we would agree on! :-)
:)
But at the risk of breaking compatibility with some validators / XML tools / etc.
It still looks like valid XML to me. Where is the incompatability? Am
I missing something obvious?
And it is. However if you have, say, <div id="[% VAR object.id %]"> then
it's not XHTML anymore (spaces / weird chars not allowed as
identifier...). I'm sure there's many more cases of nasty surprises.
There's also cases in which with TT or H::T you have:
[% IF expression %] <foo> [% FOR other_expression AS stuff %] ... some stuff </foo> [% END %] [% END %]
Here the problem is obvious because the code is well indented. However with TAL syntax this simply cannot happen.
Also, with TT you have to use the filter 'html' to XML encode your variables. Petal does it by default, and you need to use the TALES 'structure' keyword to NOT encode.
This is because double encoded values are much easier to spot and debug than badly encoded ones.
To summarize, I think Petal is more specialized in XML templating and
has the strength of a very smart, open specification written by the Zope
people. Petal fills a niche across the XML and the templating world and
is certainly not a replacement for TT.
Actually, as Steve Purkis suggested on the Petal mailing list it would be possible to implement Petal on top of TT. Maybe for Petal 2.00!
To conclude, and in order to satisfy my little ego I think both
libraries are deadly cool. Plus I would never have dreamed of the author
of TT arguing about the pros and cons of TT vs Petal with me when I
started writing the library a little more than a year ago.
That in itself is a great reward :-)
Cheers, Jean-Michel.
