Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Petal, Perl Implementation of Zope's TAL

posted by pudge on 2002.10.14 15:20   Printer-friendly
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."
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Hmmm, I appear to be having this rant quite a lot recently. Anyway, here we go:

    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 tha

    • 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.


      @JAPH = qw(Hacker Perl Another Just);
      print reverse @JAPH;
      • 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 n

    • 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.


    • 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 t

  • 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:

    1. Getting rid of those globals, otherwise a modules using petal are likely to screw up other modules using it. Take a good look at how TT2 and HTML::Template's APIs work. Yes, local $Petal::foo can work; no, not enough people know (or are likely to remember to use) local().
    2. Be a polite user of the CPAN commons. try to find a top level namespace
    • 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 [].

    • 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 n

      • 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

      • Here's what

        <?foo a="b&quot;"?>


        looks like to an XML parser (much snippage):

        $ 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 &quot; and " in the parsed output; this pretend attribute synta

  • 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.

  • I've been playing with Petal for about three weeks now and I must confess that I'm sold. It was a bit of a mental leap for me having been working with standard templating systems for a long time, but once I read up on the whole TAL concept I could see the advantage.

    It's really nice for generating static web sites. The fact that it isn't joined at the hip with mod_perl gives it a nice low threshold for developers who want to use it.
  • the store-variables-in-attribute templating thingie actually originated from the Enhydra guys (the Java camp). come to think of it, Zope is certainly not the first "object publishing" product in the market.

    this is not by any means to dismiss Zope, just that the ideas are not novel.