[Petal] Various things

[Ronald Hayden]

> I must confess that as far as I'm concerned Petal is a finished product

I agree with this -- I've used Petal extensively in multiple projects 
now, and don't particularly need new features.

To bring up an old discussion, what I could use is much more extensive 
documentation/samples.  I have my own idiosyncratic way of using Petal, 
which is cobbled together by looking at the documentation and guessing 
what it means.  Often I guessed wrong it seems, as Jean-Michel wasn't 
very impressed with the sample code I posted...:)

  -- Ron


On Wednesday, July 9, 2003, at 5:17 AM, Jean-Michel Hiver wrote:

> Hi List,
>
> Since it's almost a year since Petal has been written, I would like to
> think with you in the future direction we want Petal to head towards.
>
> * It doesn't do METAL macros.
> * It has poor error reporting.
> * It is not properly compliant with TALES...
>   (but PETALES syntax is already too limited, and TALES is even more
>   imited than that)
>
> * the UGLY syntax is ugly, but sometimes necessary.
> * caching involves writing temp files with can be a security problem.
> * it can be sometimes cumbersome to write.
>
>
> Let's take it point by point:
>
>
> 1/ It doesn't do METAL macros.
>
> I must confess that I do not fully understand METAL macros. They seem 
> to
> be some kind of includes inside-out. Apparently the advantage is that 
> it
> is more WYSIWYG-compatible that an include statement.
>
> Anybody has a full understanding of METAL? What steps would a METAL
> implementation involve?
>
>
> 2/ It has poor error reporting.
>
> Again this is a big problem. We want to support a variety of parsers
> which process a file format which is not line-oriented, yet it would be
> very nice to get more syntax checking and better error reporting.
>
> Any idea on how to implement this?
>
>
> 3/ It is not properly compliant with TALES.
>
> Maybe we need to make the expression parser more pluggable. What about
> modifiers? Should they be inside / outside the expression parser? 
> Should
> we provide ways to redefine the Petal expression syntax?
>
>
> 4/ The ugly syntax is ugly
>
> Don't know what to do about that :)
>
>
> 5/ Caching involves writing temp files with can be a security problem.
>
> I know you can turn the cache off, but... Wouldn't it be better to
> always do in-memory conversion and avoid potential security risks? 
> Maybe
> turn caching on only if the programmer provides a temp directory to
> write to? How about we use a more formal cache module, such as
> Cache::Cache?
>
>
> 6/ It can sometimes be cumbersome to write.
>
> It would be nice to have more control in order to be able to extend the
> TAL syntax. For example, someone on the ZPT list proposed a brilliant
> idea, which was to have to extra TAL attributes:
>
> <quote>
>   Add two new TAL attributes, "repeat-define" and "repeat-condition".
>   These have the same semantics as "define" and "condition", 
> respectively,
>   but when combined with a "repeat" attribute, they get executed once
>   per loop iteration.  I would be able to rewrite the above example 
> like
>   this:
>
>   <tr tal:repeat="item here/objectItems"
>       tal:repeat-define="key python: item[0]; value python: item[1]"
>       tal:repeat-condition="python: value.date < expiration">
>     <td>...</td>
>     <td>...</td>
>   </tr>
> </quote>
>
>
> Also, I think it would be really nice to be able to define new
> namespaces and operation associated with those namespaces. For example,
> instead of typing:
>
>   <a
>     href="#"
>     petal:content="self/description"
>     petal:attributes="href     self/uri;
>                       title    self/title;
>                       dir      self/dir;
>                       align    self/align;
>                       lang     self/lang"
>> Hello</a>
>
> It would be nice to be able to say:
>
>   <a
>     href="#"
>     petal:content="self/description"
>     attr:href="self/uri"
>     attr:title="self/title"
>     attr:dir="self/dir"
>     attr:align="self/align"
>     attr:lang="self/language"
>> Hello</a>
>
> (There is still the problem of setting something like xml:lang since 
> you
> cannot write attr:xml:lang="self/language"...)
>
>
> I must confess that as far as I'm concerned Petal is a finished product
> in the sense that it provided our content management system MKDoc with 
> a
> robust templating system which was the original intention. It certainly
> took some time...
>
> As we intend to modularize and open-source other bits of our software I
> might not have as much time for Petal as I had in the past because I'll
> have to maintain other modules.
>
> But it doesn't mean Petal is dead! I am commited to do bug fixes and
> continue maintaining the patch / release process.
>
> If you have any suggestions, please share. In particular any suggestion
> regarding METAL support and improved error reporting, which I think are
> two important features missing from Petal.
>
> Cheers,
> -- 
> Building a better web - http://www.mkdoc.com/
> ---------------------------------------------
> Jean-Michel Hiver
> jhiver at mkdoc.com  - +44 (0)114 255 8097
> Homepage: http://www.webmatrix.net/