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?))
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 :)
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?))
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
Sucks
Rules
Is Great
Is fun
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:
$some_content
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,
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 %]
[% FOR other_expression AS stuff %]
... some stuff
[% 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?))
> If you like a more straightforward approach, TT also lets you write: > > > $some_content > > > 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, 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 %] [% FOR other_expression AS stuff %] ... some stuff [% 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?))
Jean-Michel Hiver wrote: > something like: > > > > > > 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. [% some_content %] >dir="ltr" > petal:attributes="ltr language_dir" > petal:content="some_content"> > > > Hello, World > 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: > > > $some_content > If you like a more straightforward approach, TT also lets you write: $some_content 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
[OT] About XML and Petal (was Re: templating system opinions (axkit?))
> XML syntax is crufty at best. It requires you to be strict and tediously > correct with every character. So what. It's not like you can afford to forget that many curly braces or semicolons (well, except those at the end of a block) with Perl. That doesn't make it useless does it? > You have to shoe-horn the semantics of your complex directives into > the limited syntax of element-name-and-attributes. If you're crazy enough to use XML as a programming language, I have to agree with you. XML really sucks at that. However as a data exchange format I think it's fine. I think the same idea is behind AxKit's XPathScript. Let's use programming languages to program, and XML as a vector to structure and transport data. > The language becomes contrived and clumsy as a result of trying to satisfy > a purity of design and you find yourself tied down to only generating valid > XML (which few real world web pages are, even if they should be). Well, I see Petal's ability to help you generating valid XML webpages as a good thing. I do not recommend Petal to people who are interested in generating HTML 3.2 pages full of tables, font face tags, fixed width fonts and other javascripteries. They would be very disapointed. > The templates becomes harder to read and write because they're > designed to satisfy an XML parser rather than a human. By using XML > directives in XML markup, you ensure that the directives are > camouflaged nicely and blend into the background. This is precisely > what you (well, I) don't want to happen. These directives are > supposed to be important - they are a separate concern from the purely > declarative markup surrounding and deserve to stand out from the > crowd. I suppose that's one way of seing it. The problem is that your template then looks like a programming language, which kind of defeats the purpose of having a template in the first place. I suppose that Petal is philosophically closer to HTML_Tree, except it has a much gentler learning curve IMHO. > This is all personal opinion, of course. Same here :) > I drank the XML kool aid for a long time, until I realised it was > nothing but water, sugar and artifical colours. XML still serves a > useful purpose for many things, but it's not the uber-solution to all > our problems that vendors of commercial XML software would have us > believe. Just because you can write programs, or SQL queries, or > templates using XML, doesn't mean that you should. I agree on that. > For the record, Petal looks like a well implemented template module, > and I'm glad to see another high-calibre one joining the collective. > I've looked at TAL before and while I understand the design philosophy > that they're trying to promote, I still not that impressed because I > can see what look like gaping holes in the reasoning behind it. Maybe... It's a little bit strange when you get started with it, but it becomes clear and very elegant quite quickly. For example with a traditional mini-language kind of templating system, you might have something like: Which is completely impossible to validate and IMHO very hard to read. With Petal you just start with a mockup: Hello, World And then you add TAL instructions: > Hello, World If you like a more straightforward approach, Petal also lets you write: $some_content But at the risk of breaking compatibility with some validators / XML tools / etc. > Vive la difference! Entierement d'accord :) Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
