On 12/30/05, Alexander Limi <[EMAIL PROTECTED]> wrote:
> On Thu, 29 Dec 2005 15:49:46 +0100, Philipp von Weitershausen
> <[EMAIL PROTECTED]> wrote:
> > I think it would be quite possible to do explicit key or attribute
> > lookup with TALES, e.g.:
> >
> >   foo/attr:bar  (for foo.bar)
> >   foo/key:bar   (for foo['bar'])
> >   foo/item:1    (for foo[1])
> This reminds me of a thing Steve Alexander and myself talked about when
> working together on a project using Zope 3 a while back:
> One of the ugliest and most error-prone parts of TAL is its handling of
> multiple attributes:
> <a tal:attributes="href some/url;
>                     title some/title;" />
> etc.
> We looked at having a separate namespace for these kinds of statements.
> The above code would then be:
> <a attr:href="some/url"
>     attr:title="some/title" />
> thus doing away with the need for semicolons and the "should the last line
> have a semicolon or not" confusion.

Maybe it's the crack talking, but I'm vaguely remembering
conversations about syntax like this from back in the early days of
TAL specification development. Of course, back then TAL was aiming to
be a very-good XML citizen. And I think this meant that:

- the TAL namespace had a limited and proper list of attributes. A
very limited set of names that could be (theoretically) validated with
standard XML tools.
- XML processing, if I recall correctly, does not cover ordering of
tag attributes, nor gives them any significance. You couldn't have
'attr:title' have any dependency on 'attr:href', for example.

As a result, there are a limited list of TAL keywords with a well
defined order of execution.

How would these namespaces impact that? When doing "proper" XML
processing with TAL, would the 'attr' and 'defines' and other
namespaces all need to be explicitly loaded?

I neither love nor hate the semicolon to separate statements - except
in string: expressions. I'm still not sure how to properly escape them
there. I like that I can do multi-line strings as a single statement
(useful for JavaScript when one's given Dreamweaver mouseover code).
But I sometimes get too many semicolons showing up in some javascript
onFoo attributes (like trying to generate an onLoad for a page that
could define additional onLoad events, although I've found other ways
to get around that).

> The same would probably be relevant for tal:defines, something like:
> <div define:mammals="here/getMammals"
>       define:fish="here/getFish"
>   />
> This provides the following benefits:
> - Easier to parse for XML tools (no semicolons with any meaning)

See my concerns above. They might not be real concerns, but they're
little things I remember coming up in early TAL discussions.

> - More consistent syntax, no need to learn a special way to separate
> several attributes/defines

No, instead one needs to learn a large crop of new namespaces on top
of the regular TAL and METAL ones, and how their order impacts other
TAL statements. More namespaces increases the chance of namespace
collision. What impact does this have on other TAL statements
(condition, repeat, etc) - are they still in the tal: namespace?

TAL and TALES have a very simple and well defined syntax as they are.
This proposal adds in some special cases. Learning to use a semicolon
as a way to separate statements is not that hard to learn. If you have
multiple statements on a single line of Python, you have to use a
semicolon (some situations make having this nice). If you have
multiple JavaScript expressions in an event handler in HTML, you
separate them with a semicolon.

> - It looks nice! :)

That's relative. I love the simplicity of TAL and basic TALES
expressions. There are other things about TAL/TALES these days that
bugs me. The special TALES path namespaces like zope:title_or_id - I
wish it was easier to discover what things like that are defined and
how to define ones own. That's a feature that I often forget is there,
and there may be some helpful things in those namespaces that I'm not
even aware of.

> For the record, I'm also for getting rid of the python: stuff in TAL, but
> only if we can solve the common use cases others have identified earlier
> in this discussion. Making ZPT carry less smarts and preferrably get it a
> bit faster would be very welcome in my universe. :)

I think that separating the attrs out into individual calls makes TAL
have to carry more smarts.

By the way - a common situation I was reminded of while typing all of
this: no boolean expressions for doing things like 'ensure a false
value is an empty string'. I know you can do things like
"path1/path2|string:" but that only works if that path can't be
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to