[Zope3-dev] Number of languages in Zope 3

[Joachim Werner]

Peter Simmons wrote:
> I think you guys are forgetting that paths are very useful and more 
> natural to people who just design.
> 
> That is where we have found the most use for them, allowing designers 
> (people who never code) add a little bit of dynamcism to the pages. It 
> means they need to ask coders to do less especially when it is changing 
> the presentation.

But that exactly is my point: If you are a designer and get to know the 
basic bath-based ZPT/TAL syntax then you have some promising success at 
the very beginning (adding a here/title works fine). But as soon as you 
need to use something a bit more advanced you have to learn another, 
different syntax. And this process is much more time-consuming and 
frustrating than having to learn an only slightly more complicated 
syntax at the beginning.

This is my personal experience from DTML. If the early DTML 
documentation had told people about the basics of Python expression 
syntax (why and when you need the different brackets, when exactly you 
have to use "" etc.) things would have been a bit more complicated for 
me at the beginning (<dtml-var title_or_id> looks slightly easier than 
<dtml-var "title_or_id()">), but I would have saved a lot of time 
figuring out all the rest.

I remember lots of postings from zope.org where people asked things like 
"I have tried it with and without the quotes, tried adding brackets, but 
it still won't do what I want it to do ...".

I don't know how current Zope first-timers get along with ZPT, but 
considering that ZPT is much more complex in syntax I can't believe that 
things have become better now.

You seem to think that there is a clear line between what designers who 
need some dynamic effects on their pages do and what "real" programmers 
do with Zope. But that's not true. Even for seemingly simple things it 
might be necessary to get into python-style syntax. And then why not 
learn it from scratch?

One example: If you just need to place an image in a ZPT template, the 
syntax (at least one of the hundreds of possibilities) is

<img tal:replace="structure here/Imagefolder/imagename" src="" />

This is already quite challenging because of the "structure" directive 
you need, which is hard to explain to a beginner.

But now you want to add a custom title attribute. Just because of this 
you have to switch to a completely different syntax:

<img
   tal:replace="structure 
python:here.Imagefolder.imagename.tag(title='MyTitle')"
   src="" />

This is even hard to get for somebody who knows Python because you are 
limited to having to use single quotes in the brackets due to some 
limitation of the TAL parser.

Well, there is a path-based alternative, but now it's getting really ugly:

   <img tal:attributes="
     src here/Imagefolder/imagename/absolute_url;
     width here/Imagefolder/imagename/width;
     height here/Imagefolder/imagename/height;
     alt here/Imagefolder/imagename/alt"
     title="MyTitle" />

This uses only paths, but the user has to know absolute_url, know about 
the exact set of properties provided by the image object, and has to 
write a lot.

Of course you could define a shortcut variable for 
here/Imagefolder/imagename, but then it is completely out of reach for a 
beginner.

Remember that what got us into this is the simple desire to have a 
custom title for an image.

The example that would be the most "forward-compatible" would be this one:

<img
   tal:replace="structure python:here.Imagefolder.imagename.tag()"
   src="" />

If we always used Python syntax then it could even look like this:

<img
   tal:replace="structure here.Imagefolder.imagename.tag()"
   src="" />

If that was the standard way of doing things, it would be easy to 
explain that you get a custom title by passing it to the tag() method as 
a parameter.

Now we just have two problems left:

a) the "structure" keyword that is really hard to get

b) the fact that we now get into trouble if the image is called 
"imagename.gif" ... (one, not completely satisfying solution would be to 
use "/" instead of dots, but allow calling methods(), something like:

here/Imagefolder/imagename/tag()

So the bottom line is that the current DTML and ZPT syntax is a mess ... :-(


Joachim