[Petal] Interoperability

[Jean-Michel Hiver]

> ><ul petal:if name="here.children">
> 
> I hope you meant "confition".

No, rather 'condition' :-) You might find it completely outrageous, but
Petal allows you to use either. If you're a lazy person, petal:if will
be definitely more appealing than petal:condition!

> >object.method.method2
> 
> What does this mean?

It means invoke method2() on the object returned by method() on the
object 'object'.


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

By default you pass string arguments. I plan to introduce escaping, so
that you'll be able to write:

object.something some\ string\ with\ space\ in\ it. $some_variable

and maybe:

object.something "some string with space in it" $some_variable.


I still have to think about all this!


> >And you can also recall existing values...: object.add 2 
> >$object.current_value
> 
> Why is a $ needed here?

You use the dollar to recall the existing value.

How does TALES solves this?


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

Aaaaah I see. I didn't quite get that. Well that's interesting, I think
I'll implement it at some point.


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

I'm not sure to follow what you mean...


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

Aaah, valid point. How about escaping? i.e. image\.gif...


> Five reasons:
> 
>   - Interoperability
> 
>   - '/' is more general that attribute lookup.
>
>   - Interoperability
> 
>   - People might want object names that contain dots.
> 
>   - Interoperability.

>   - Interoperability

I don't really see why / is more interoperable that ., apart from
interoperability with Zope maybe...

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

'/' is just a symbol. Saying it's more general is just a Python way of
looking at it. Arguably, '~' would have been even more meaningless and
therefore more general. '/' makes you think of a hierarchy, which is
not necessarily desirable outside Zope.

>   - People might want object names that contain dots.

Yeah, well, and people might want objects names containing slashes...
honestly I think the only reasonable alternative is to backslash
special characters. It's easy to implement, easy to use, it's good :-)


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

Cool, we agree to agree then :-)


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

Aaah, tell me more about it. How would it look like?


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

If I used Perl expression syntax, the temptation would have been too
great to do eval "$expr" and thus let the user access the whole Perl
thing.

I don't want that. I don't want users to type $foo->bar > $baz.
Mixing P(erl|ython) with templates is the root of EVIL.



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

No, it's not. But it forces you to put your code in methods rather than
embed it in the template.

Besides, '>' and '<' *should* really be &lt; and &gt; shouldn't it?

len(results) &gt; 20

Is a lot less 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?


I don't know about it. What does it look like?


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

I find the string: expressions very interesting!


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

OK. In Petal, path: is the default. Is it necessary to specify the
expression type in TALES or is path: the default as well?

string: is very interesting. I'll implement it.


> I wonder of the tal: namespace used in Petal could use TALES as it's 
> expression
> language.
> 
> What are :true and :false used for?

:true will be true if the variable is true. If the variable is an array
reference, :true will be true if it's not an empty list.

:false is the opposite of :true. :not is an alias for :false.


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

You can do <p petal:define="fooBar foo.bar"> and then use fooBar instead
of foo.bar.

I'm not sure I really grab the 'structure' concept yet.


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