[Petal] Re: Looking for Petal info

[Jean-Michel Hiver]

CC'ed to the Petal mailing list...

> This probably comes way too late in your design process, but I'll give 
> you my thoughts on Petal anyhow.  The pain we went through in designing 
> ZPTs has to be good for something!

This is far from being too late, Petal is still alpha / beta, so if you
come up with overwhelming good reason (and -jeez- you're on your way)
I'll just change the way everything works!


> Python uses '.' to denote object attributes; we chose '/' for the TALES 
> Path Expression type for two reasons: first, because it mapped very 
> nicely onto the Zope URL-as-ORB-name concept (including dealing with 
> objects whose names have extensions e.g. "button.gif"), and secondly in 
> order to emphasize that '/'-traversal is *not* equivalent to attribute 
> access.  Paths mean whatever the implementation wants them to mean.

What I plan to do in the near future is to introduce backslashing in
Petal expressions. This way it'll be possible to write:

object.image\.gif

I'll also introduce 'slash' as an alternate '.' operator, so that:

object/image\.gif

Will be possible. Would that be acceptable?


> notation:
> 
>   <tal:bday condition="user/is_birthday">
>     Happy Birthday, <tal:name replace="user/real_name"/>!
>   </tal:bday>
>   <tal:nbday condition="not:user/is_birthday">
>     What?! It's not your birthday?
>     Maybe tomorrow...
>   </tal:nbday>

I see.... interesting. The reason for which I chose XML PI is because it
was supported straight away by HTML tidy...

I think I'll probably add your way of doing things to the exising
syntax. Yes, There will be Yet Another Way Of Doing It :-)


> We have considered using PIs, but only as behavioral switches placed 
> above the top-level tag, as in '<?metal use-macro="..."?>' to use a 
> macro that includes the opening '<?xml...>' and '<!DOCTYPE...>'.

Yeah, well, I can't get my head around METAL yet, which is why I have
includes :-) When I have a TAL and TALES compatible enough module, I'll
take a look at it.


> You appear to have discarded TALES in favor of a single all-encompassing 
> expression type, but then brought it partly back in through the back 
> door in the form of expression modifiers.  The advantage of TALES is 
> that it allows for any future expression syntax you like that can be 
> made to fit in an XML attribute.  A concrete example is the XPath 
> expression type that one of the ZPT community members created.

I think that TALES and expression modifiers are pretty much the same...


> How would you spell the Petal equivalent of '<a tal:attributes="href 
> string:$base/$path">'?  Does interpolation work in attributes?

Well, in this case, I'd write directly: <a href="$base/$path">

But I now see the point in ':string', I think it's interesting, I thing
I'll write a modifier :string. And while I'm at it, I might change the
modifier from :modifier to modifier: if it's more TAL compliant.


> Do you expect inserted text in Petal to be predominantly structural 
> (i.e. containing un-encoded markup) or textual (encoded)?  We chose 
> encoding as the default, requiring the user to explicitly choose not to 
> encode, because we found structural insertions to be rare.  More 
> importantly, forgetting to use the 'structure' keyword tends to produce 
> blatantly, glaringly wrong results right away, whereas forgetting in the 
> other direction produces a subtle bug that is often not noticed until it 
> is accidentally triggered (or exploited!) much later.

Interesting point indeed! I might change it to be the default then...


> The reason for TAL's 'repeat' namespace is twofold: it allows you to 
> avoid peculiar 'magical' names such as '__count__', and it allows you 
> full access to loop metadata in nested loops.  Consider:
> 
> <tr tal:repeat="row rows">
>   <td tal:repeat="col cols">
> Row <tal:x replace="repeat/row/index" />,
> Column <tal:x replace="repeat/col/index" />
>   </td>
> </tr>

Well, here I'm not really convinced. You still have a special variable
'repeat'. And repeat/row/index is longer than __count__. In Perl
culture, 'magical' variables are not necessarily a Bad Thing :-)


Cheers,
-- 
IT'S TIME FOR A DIFFERENT KIND OF WEB
================================================================
  Jean-Michel Hiver - Software Director
  jhiver@mkdoc.com
  +44 (0)114 255 8097
================================================================
                                      VISIT HTTP://WWW.MKDOC.COM