[Petal] Re: Looking for Petal info

[Evan Simpson]

Jean-Michel Hiver wrote:
> CC'ed to the Petal mailing list...

Hello all! I'm properly subscribed and caught up on the archives now.

> I'll just change the way everything works!

Please feel free to ask me about any aspect of TAL/TALES/METAL that you 
find unclear.

> Will be possible. Would that be acceptable?

 From an interoperability standpoint, it will get us halfway there.  It 
would help if you warned the user if a single expression used both 
periods and slashes unescaped, as in "here/button.gif", since that would 
help the unwary.

Jim has pointed out the true meaning of '|' and '/' in TALES path 
expressions, but I feel the need to explain a little more.  Let's look 
at a fairly common ZPT idiom:

   Hello, <span tal:content="value request/cookies/username | 
default">Anonymous Coward</span>

In this example, the 'request' variable is a container for HTTP request 
information.  It has a 'cookies' attributes that is a hash.  If there is 
no cookie named 'username' in the request, the expression will fall back 
to the value of 'default', a standard TAL variable.  This value tells 
TAL to leave the contents of the <span> alone.

   <script tal:condition="not:inline_js"
    tal:attributes="src library/common.js/absolute_url"></script>
   <script tal:condition="inline_js"
    tal:content="library/common.js"></script>

In this example, 'library' is a container for a set of file objects. 
Each file object has an 'absolute_url' method, and produces its contents 
when asked for a string.  This demonstrates the fact that, while you are 
hardly likely to define a variable with a period in its name, you may 
easily have a hash or other containerish object with periods (or odder 
characters) in its keys.  Of course, there's no reason why such a key 
couldn't contain a slash, so an escape mechanism is necessary.  It's 
just that *nix filesystem names and URLs provide negative reinforcement 
for slashes-in-names and positive for dots-in-names.

>>  <tal:bday condition="user/is_birthday"
> 
> 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 :-)

The 'tal:bday' bit arises from the fact that we allow *any* 
syntactically valid tag name in the TAL and METAL namespace, and choose 
to place attributes that lack explicit namespace prefixes in the same 
namespace as the tag in which they occur.

A further note on this: although ZPTs will accept undefined 'tal:' and 
'metal:' namespaces in HTML without any fuss, they require a proper 
namespace declaration in XML.  To make this behaviour properly 
consistent, these prefixes are *not* hardwired.  You could write:

<library xmlns:frotz="http://xml.zope.org/namespaces/tal">
   <book frotz:repeat="volume volumes"
         frotz:attributes="author volume/author" />
</library>

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

At it's core, METAL is indeed an inclusion mechanism.  A METAL macro is 
evaluated in the context in which it is used, including defined 
variables.  Additionally, you can define 'slots' in a macro, which are 
essentially arguments to the macro that consist of entire XML elements.

There's an additional dimension to METAL, having to do with 
designer-friendliness.  When a designer edits the source of a template, 
they can see the macros expanded inline, but can only edit the contents 
of slots, not the macro bodies.

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

Ah, so an expression modifier has complete control over the syntax of 
the expression it modifies?  This wasn't clear to me, since all of the 
example expressions seem to have the same "a.b.c [arg1] ..." format.

> modifier from :modifier to modifier: if it's more TAL compliant.

Please do :-)

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

Unless I'm misunderstanding you, though, __count__ would be equivalent 
to repeat/col/index (the inner loop), and there would be no way to spell 
repeat/row/index (outer loop) in the same scope, except perhaps to 
define="outercount __count__" in the outer scope.

Cheers,

Evan @ 4-am