[Petal] Interoperability

[Jim Fulton]

Jean-Michel Hiver wrote:
>>>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).
>>

...

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

I hope you meant "confition".

...


>>Could you list any additional features, as opposed to simple differences?
>>
> 
> Petal expressions, as opposed to TALES, work as follows:
> 
> value
> object.method

These aren't really new features, as TALES has an equivalent spelling.


> object.method.method2

What does this mean?

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

This is very TCL-esque.

Can you pass string arguments? If so, how are they spelled?

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

Why is a $ needed here?

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

The '|' in TALES path expressions is not a separator. It is an or operator.


> Petal does not use '/' for method invocation but '.'.

The '/' is not a method invocation operator, but a sub-object access
operator. It is used both for attribute and item (mapping/hash) lookup.


 > This is because
> most object oriented languages (including python!!!) use the dot or are
> going to switch to the dot (Perl6...).

In Zope, objects can have dots in their names. The slash is disallowed.
If people build content-management systems in perl, I suspect that they
will run into similar situations.

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

Five reasons:

   - Interoperability

   - '/' is more general that attribute lookup.
   - Interoperability

   - People might want object names that contain dots.

   - Interoperability.

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

OK.

....

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

OK

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

See above.

Note that TALES *does* use ';' as a separator in situations where
a separator is needed.

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

Note that TALES already has a way of accepting multiple syntaxes, refered
to as expression types. If you *really* want to stick with your syntax, then
it could be provided via a TALES expression type.


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

Good.

 > and that is why I will
> never include a :perl modifier in Petal (although it'd be dead easy to
> write your own).

But you've written your own expression syntax. No offence, but that seems
worse that sticking with a syntax your users already understand.


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

Yes, you are, which is why we try to avoid Python expressions in templates.


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

Do you think that this is more readable?


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

Perhaps, although there are often more than two states that must be considered.
In the example I gave, IN the example I gave I was thinking of three cases: no results,
few results, and so many results that batching would be necessary.

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

I agree that it would be better to have very simple conditions to check that
don't require operatoes or arguments. If we do need arguments or operators,
I think operarators are more readable.

I wonder if something like the Object Constraint Language would be
a good choice as a language-neutral expression syntax for simple
conditional expressions?

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

I wouldn't expect you to implement the Python expression type.

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

OK, path expressions are all about object traversal. They
are basically object names. They were designed under the assumption
that object names could contain almost any characters. In particular,
object names can contain dots.  Imagine that some perl program
lets users create and name content. Maybe the users can upload files
and want to use the same name for the content as was used for the files.

Path expressions are the default expression type. They allow two
operators:

   '/'  - Object traversal. This could be an attribute access or an item
          access. (These concepts may not be distinct in perl.) An application
          might also have a framework that allows objects to provide specific
          traversal semantics.  The '/' operator was chosen to echo URL traversal.

   '|'  - Alternative operator.  The expression a/b|c means, get a/b if you can,
          but, if you can't, fall back to b. Read a/b or c.

   There's also a proposed syntx (OK, implemented and undocumented) that allows
   you to use variable names in path segments, as in: a/?d, which means traverse
   a with the name in variable d.

String expressions are for computing strings using a familiar string interpolation
syntax. This is most often used when computing attribute values:

   <a href="foo"
      tal:attributes="string:${content/absolute_url}/foo">

Note that not:, path:, and string: are the only required expression types
in TALES.

I wonder of the tal: namespace used in Petal could use TALES as it's expression
language.

What are :true and :false used for?

Is TAL's "define" implemented? How about "structure"?

...

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

Great!

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org