Jean-Michel Hiver writes "These guys from Zope have really interesting ideas. Among then is a really cool spec called TAL that lets them build WYSIWYG-friendly template by just using HTML attributes rather than having special extra tags. Petal is an attempt to reproduce TAL functionality in Perl and also to take it further by enhancing its syntax and XML processing capabilites. Check out the documentation and mailing list."
Everyone seems to write their own template system with slightly different syntax / features and then upload it to the CPAN. Far be it from me to dissuade you doing the same.
Have you read Choosing a Templating System?
What does TAL provide that, say the Template Toolkit or AxKit does not? Wouldn't it be better to rely on a module that has had years of testing, complete documentation, an active support group and many users than roll your own? Surely patching an existing module is a much better use of your resources than maintaining a new one?
Grumpy old Leon.
PS "Compatibility" is a good answer, but not if your fork off from the TAL spec later on.
PPS And don't get me started on those Acme:: modules...
Re:Another templating system?
TeeJay on 2002-10-15T09:03:37
I think this templating system is well justified because it would allow Zope and Python users to migrate to perl.More importantly it means that Zope-Compatible or Competitive CMS can be written in perl.
One of the great things about Open Source is the level of competition and also the way in which many components are fairly easy to interchange.
Re:Another templating system?
ignatz on 2002-10-15T16:36:21
I think that it is important to note that Zope-Tal/Petal interopability is not a goal of the Petal project. I asked about Zope-Tal/Petal interopability on the Petal mailing list. Here's Mr. Hiver's response:
>> Is keeping things in sync between Tal and Petal a goal of the project?
No it isn't. The goal of the project is to make a useful library to template any kind of XML and XHTML. The TAL spec was a good place to start, it has plenty of really good ideas.
Now I had my own good ideas as well that I needed to integrate in this library:-)
However, wherever I can, I try to make the library as TAL-compliant as I
can because it's good practice.
> What problems would there be in having language neutral templates?
Unfortunately TAL is not that neutral, it's been designed for Zope. I you limit yourself to the intersection of features between TAL and Petal, you could very well write templates that run on both engines, but you'll loose functionality for either side.
A grand unification between Zope and Perl does seem interesting, but I wonder how realistic this is.Re:Another templating system?
Dom2 on 2002-10-15T12:36:43
It's different to all the others because it doesn't interfere with XML/SGML validitity and well formedness. That's enough to make me very interested in it.-Dom
Re:Another templating system?
jhiver on 2002-10-15T15:32:12
Actually, yes I _DID_ read Perrin Harkins' Choosing a Templating System article and none of the templating systems listed here offer the same functionality as Petal.
I have sent an email to Perrin Harkins and here is an extract of his reply:
Because there are so many template tools (literally dozens) and most of them have very few distinguishing features, I try to limit the number of tools described in detail in my document.In general, I have only talked about the most widely used ones, and just listed the other interesting ones briefly. However, Petal has a special appeal for people who want to use standard HTML for their templates (the "TAL" syntax), and the module I currently list for that is not well supported anymore, so I was planning to list Petal there.
That should answer your question. It is my feeling that Petal *DOES* fill in a niche in the Perl templating world.
Re:Another templating system?
acme on 2002-10-15T15:51:54
OK. That's fine then;-)
Nice twist on the old templating system scheme. Not sure CPAN needed YATS, but hey, it's a commons, post bills where you may.
A few issues you might consider:
local().You might want to warn about esaping issues in PIs, since the fake attribute in may not parse right if you stick a " in the same string as the "b". This may not be an issue in your instance, but you might want to think about it. How (well?) does this interoperate with XML namespaces? - Barrie
Re:Nice, but...
snowball on 2002-10-15T15:30:39
How (well?) does this interoperate with XML namespaces?
This is near the top of Jean-Michels TODO list and it will get fixed.
I also want to see support for Xincludes.
Re:Nice, but...
jhiver on 2002-10-15T16:14:24
Globals. As for getting rid of the globals, why not, but I'm pretty sure that I have made it so that it is not likely to be screwed by other modules... I have also spent a great deal of time making sure that Petal leaks no memory for persistent environments a la mod_perl. In other words, I'm not sure about what you mean. Can you give a better explanation?
As for CPAN namespace, there was a bit of a fight on the modules list about it. Basically the suggested name was Template::Petal. I think that generic names like 'Template' or 'CGI' which are attributed to specific modules are a terrible mistake.
If the Template Toolkit was in the 'Template::Toolkit' namespace, I would have no problem renaming 'Petal' to 'Template::Petal'.
However that's not the case. If I renamed Petal to 'Template::Petal' it would merely sound like some kind of plugin for the Template Toolkit, and because of the 3rd virtue I cannot do that
:-) I don't really understand your comment about processing instructions. Would you be so kind as to give an example, so that I can check that Petal has the proper behavior.
Re:Globals
barries on 2002-10-15T17:44:31
Consider an app that wants two petal processors; how do you allow that app to configure them differently? Right now, the user has to be a bit savvy and write a wrapper sub, preferably using local() to set each of the $Petal::foo settings the way they want. By allowing
my $p = Petal->new( %options );You offer the service of encapsulation in addition to the service of handling templates. Now maybe Petal does that under the hood, but the docs say that you have to set some options as globals and others (file => ) passing in to new(). Petal currently thinks of an instance as being one file; I'm suggesting that one instance is more powerfully thought of as one processor which can process multiple files. That way the settings for a processor can be persistent across requests and files, but the files are transient.
In my experience, larger systems benefit from the instance-as-processor approach being primary instead of only offering the instance-as-file approach
- Barrie
Re: PIs & quoting
barries on 2002-10-15T17:54:34
Here's what
looks like to an XML parser (much snippage):<?foo a="b""?>
<snork/>$ perl -d:TraceSAX -e 'use XML::SAX::PurePerl; XML::SAX::PurePerl->new->parse_uri( "foo.xml" )'... start_document( {} ) ... processing_instruction: <?foo a="b""?> ... start_element: <snork> ... end_element: </snork> ... end_document( {} )
Note that there is no differentiation between
"and"in the parsed output; this pretend attribute syntax can lead people in to thinking that they can put "e; in these attributes. This may or may not be a problem with Petal; if it only ever allows/needs non-escaped things in these pretend attributes, it's not.- Barrie
I, too, used to think like Grumpy old Leon. I've used lots of templating libraries and often wished for a better solution but kept being disappointed with the latest template library released to CPAN. Petal is a different beast than the typical search-and-replace library.
The template attribute language (TAL) is a great solution for mini-language templates (see Perrin's Choosing a Template Language), and Jean-Michel has done an admirable job of creating a module that implements this functionality in Perl. It plays nicely with the GUI editors which my designers like to subject my templates to, it doesn't generate too many errors when scanned with HTML Tidy, and my templates look cleaner than when using custom html tags.
BTW, Perrin has told Jean-Michel that he plans to cover Petal in his next update of that article. Furthermore, if you use TT2, HTML::Template or Text::Template and pass a hash reference to these templates, it's relatively easy to convert your existing templates to Petal without many changes to your existing Perl code.
Try it! Like me, you might find it's going to become a best of breed solution for implementing HTML/XML templates.
Williamthis is not by any means to dismiss Zope, just that the ideas are not novel.