[Petal] Interoperability

[Jean-Michel Hiver]

> > Feel free to take a look at
> >the Petal documentation
> >
> >  http://search.cpan.org/search?mode=module&query=Petal
> >
> >Maybe you ought to take a look at the documentation, see what are the
> >similarities (lots) and differences (again, lots :-)) between the two
> >systems, and from there I'll happily welcome any suggestion that would
> >increase interoperability / usefullness of the package. 
> 
> OK, Thanks. I've taken a look.  I want, first, to understand the
> new features. These seem to be:
> 
> - alternative syntax ($-interpolation, and processing directives).

$-interpolation
===============

$-interpolation is based on the fact that sometimes, it might be
desirable to actually SEE a variable name in a template. I can
understand the usefullness of TAL in making complex operations like
loops and nested ifs invisible to WYSIWYG editors.

However, which one is better:

  Welcome, Dummy User! -OR- Welcome $encode:user! ??
  
That is arguable. You might want to give limited control to template
designers for example, and let them control some obvious variables. And
if you don't want to, no ones forces you to do it.


Another use of the $ish syntax can be the following:

<div class="lang-$lang">

Which would produce something like:

<div class="lang-en">

We could concatenate $lang with another string in an attribute, which
avoids unnecessary code to compute the 'lang-$lang' string.


Processing directives
=====================

They are mainly to be used when relatively complex logic has to be used,
or simply because some people (especially programmers) might find it a
more natural way of writing templates.

For example, consider:

<ul petal:if name="here.children">
  <li petal:repeat name="child here.children">
    <a href="foo"
       lang="foo"
       title="foo"
       petal:attributes="href :encode child.uri;
                         lang :encode child.lang
                         title :encode child.description"
       petal:content=":encode child.title">FOO</a>
    <a href="bar" petal:content="nothing">BAR</a>
    <a href="bar" petal:content="nothing">BAZ</a>
  </li>
</ul>


With

<?petal:if name="here.children"?><ul>
  <?petal:foreach name="child here.children"?><li>
    <a href="$encode:child.uri"
       lang="$encode:child.lang"
       title="$encode:child.description">$encode:child.title</a>
  <?petal:end?>
<?petal:end?>


The former is definitely better for WYSIWYG edition, the latter being
IMHO much smoother to the human eye... If the file is not meant to be
WYSIWYG edited, why bother with the pure TAL syntax?



> Could you list any additional features, as opposed to simple differences?

Petal expressions, as opposed to TALES, work as follows:

value
object.method
object.method.method2


But you can also give parameters to your methods: object.add 2 3

And you can also recall existing values...: object.add 2 $object.current_value


At the moment Petal does not use '|' but ';' to separate expressions.
the pipe symbol makes me think 'pipe', not 'separation'.

Petal does not use '/' for method invocation but '.'. This is because
most object oriented languages (including python!!!) use the dot or are
going to switch to the dot (Perl6...).

Why should Petal stick to Zope's standard rather than many major
programming languages?

Note that I would not mind ADDING slash as an alias to the dot, but the
dot will survive :-)


> What motivates the alternative syntaxes. The $-interpolation would
> show up in mock-ups, which would seem to be a bad thing. Are you sure
> that processing directives will be properly maintainied. Do the alternate
> syntaxes offer anything over the standard TAL syntax?

See above.


> Why use "petal:" rather that "tal:"? That difference seems gratuitous.
> Of course, when working with XML, I *asume* one could provide a namespace
> declaration and use "tal:", right?

Well, I knew that I was not going to fully implement TAL and that I was
going to bring extensions of my own, and I would not pretend using the
same namespace if the same templates don't work.

When through discussions we've achieved satisfactory interoperability
I'll amend Petal so that it can either use petal: OR tal:. In which case
tal: would support stricly tal: constructs and nothing else.


> It appears that you have invented your own expression syntax.
> I don't think that "my_array.12" is perl syntax, is it? Why not use
> "my_array/12" as in ZPT? It appears to me that your dot and ZPT's
> slash have the same meaning.

They do, but then, why choosing '/' and '|' when arguably '.' and ';'
are a lot more widely used, and therefore appropriate? I really enjoy
the TALES spec but IMHO this is a big flaw.

Besides, I really wanted to provide a way to pass parameters, and for
that I had to have pretty much a syntax of my own.


> We try *very* hard to keep Python expressions out of our templates.
> This is based on our experience with our older templating language,
> DTML, that became a scripting language through lack of discipline.

I know what you mean, I share the same feeling, and that is why I will
never include a :perl modifier in Petal (although it'd be dead easy to
write your own).


> We are very wary of making this mistake again and I encourage
> you to be wary too.  We do occasionally need simple Python expressions,
> like "len(results) > 20" in conditional statements. It would be nice if
> we (together) could come up with a simple expression syntax that was
> not Python and that could handle cases like this.

If you can pass parameters to your subroutines / coderefs / etc this is
not an issue. I would even argue that this is bad because you're
embedding some logic in the template.

With Petal len(results) > 20 would be more likely to be written:

results.length_is_gt 20

However I still think this is bad because of the '20' which is embedded
in the template.

results.length_is_ok

Seems a lot more sensible... In other words, at worst passing parameters
to methods is a nice kludge, but ideally you want to limit that using
data encapsulation.


> Your modifiers are mostly very similar to TALES expression types.
> Is there any reason we couldn't make them more similar so that
> we could have the same spelling, at least when the meaning is the
> same?

Well, ':not' is, which is a good start :-)
:python is going to be somewhat problematic I suppose!

But I don't really understand the difference between :path and
:string... any explanation / example would be welcome!


> That is a bit of a culture clash. ;)
> 
> It would be helpful if there was at least one way to do it
> with Petal that was highly compatible with ZPT.

I agree. I will need to re-write the expression engine in a much cleaner
way, I'll try to work out a reasonable draft specification and I'll drop
it on the list (probably by next week).


Best regards,
-- 
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