Re: [OT] About XML and Petal (was Re: templating system opinions (axkit?))
Le lundi, 28 juil 2003, à 21:27 Europe/Paris, Jean-Michel Hiver a écrit : 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. You don't *have* to use the 'html' filter in TT. I wrote a subclass of Template which does this automatically for me, and as with Petal I can also not encode by using a specific method. -- Eric Cholet
Re: [OT] About XML and Petal (was Re: templating system opinions (axkit?))
Jean-Michel Hiver wrote: something like: div dir=!--VAR language_dir -- !--VAR some_content-- /div Which is completely impossible to validate and IMHO very hard to read. Agreed. The following is easier to read, IMHO, and is also valid XML markup. div dir=[% language_dir %] [% some_content %] /div div dir=ltr petal:attributes=ltr language_dir petal:content=some_content Hello, World /div I accept that it's a clever approach, but I think it's the hardest to read of all three. Both the original values and also the Petal replacement instructions are present in the element. The reader has to mentally match them up to figure out what's going on. It's hard to see at a glance that 'Hello World' is replaced by 'some_content', for example, without checking the element attributes. I'm sure that once you're in the Petal mindset it all make sense much more quickly. But you're right in saying that it's strange at first! If you like a more straightforward approach, Petal also lets you write: div dir=$language_dir $some_content /div 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? A
Re: [OT] About XML and Petal (was Re: templating system opinions(axkit?))
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.
Re: [OT] About XML and Petal (was Re: templating system opinions (axkit?))
I suggest y'all check out Tapestry
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
XMLSucks/XML
Perl
UselessItemTagRules/UselessItemTag
UselessItemTagIs Great/UselessItemTag
UselessItemTagIs 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.
Re: [OT] About XML and Petal (was Re: templating system opinions(axkit?))
Hi, All May be I'm a bit late here... But is there any sence in artifical XML templating languages since there is XSLT ? Just wonder whether there are cons other than long learning curve and performance issues ? Alex Gidrevich
Re: [OT] About XML and Petal (was Re: templating system opinions(axkit?))
On Mon, 28 Jul 2003, Aleksandr Guidrevitch wrote: May be I'm a bit late here... But is there any sence in artifical XML templating languages since there is XSLT ? Just wonder whether there are cons other than long learning curve and performance issues ? Well, in the case of just TAL/Petal, the point as far as I know isn't so much that it happens to be valid XML -- though of course that's a welcome design aspect -- but that it's easy to use in W3C compliant HTML without masking the interesting bits inside HTML comment blocks. I can't think of an example now (and apologize for only having had time to skim much of this long, spiralling thread so far), but I seem to remember that TAL's syntax allowed for these clever little inside out loop structures that, among other things, ensures that the unrolled version of the loop still has proper indentation etc. Unessential maybe, but a nice touch. I don't know nearly enough about XSLT to comment on it in depth, but my impression is that TAL generally derives from the same heritage as all the assorted Perl template languages, etc, rather than ...well I guess I don't really know where XSLT derives from (Docbook?), but it seems more like CSS: a separate document describing how to display one or more other structured documents. The difference in the case of TAL / TT / H::T / Mason / etc is that the template is used to provide that structure itself, assembling it out of code that is maybe extracting content from a database or calculating it on the fly something. My hunch is that the way to work XSLT into the mix -- if it has a place at all -- is to have your logic (scripts with H::T, code sprinkled in Mason templates, TT applied where clever TT people apply it) fleshing out the framework defined in a template (the H::T template, the non-code part of a Mason template, the plaintext part of a TT template) as well formed XML, and then using XSLT to format that intermediate form for display. This probably makes sense in cases where that intermediate form can be cached (pages for web or print that change once a day, say), but for truly dynamic documents the XSLT stage is probably way too much overhead. Is XSLT appropriate for applying both structure styling to the free- form output of a [Perl] program? Does it take a lot of overhead? Would this overhead happen on the server end (glue XML + XSLT into an HTML document that goes out over the wire), or on the client end (download XML, then grab XSLT by reference (like HTML grabs CSS), and then the client merges them)? If the client does the work, how widespread is support? If the server does the work, what should the throughput be like? My hunch -- which I'd be happy to be corrected about -- is that this can't be any easier than just working directly from traditional template kits, as has been discussed at remarkable length in this thread :) -- Chris Devers[EMAIL PROTECTED]http://devers.homeip.net:8080/resume/ sorry for helping along in this thread 10 days dozens of messages ago :)
