Better access to APIs in paths (was Re: [Zope3-dev] needing views clues - template/title troubles)

[Joachim Werner]

>> The thing Zope 2 does well here is to make common APIs convenient.
>> The thing Zope 3 does well here is to be explicit.

I think explicitness can eventually lead to a syntax that is almost 
unusable for the target group here. We should really think a bit about 
the target group for content-space ZPT.

Remember that even "here/title" or "context/title" is adding complexity 
too DTML's original plain "title" ...

I'll discuss two scenarios:

a) ZPT used for defining templates in a Content Management System.

Target Group: content managers who don't know much about anything but 
content.

These people want to be able to access the properties (and calculated 
properties) of the content object the template is written for. They want 
to be able to do this using the most simple syntax one could think of. 
On the other hand, in this scenario the ambiguity of names that made the 
different namespaces in ZPT necessary will not be a major problem here.

The number of variables (or attributes) they will be using will be 
extremely limited. It's like people who just learn some phrases in a 
language to be prepared for a trip to a foreign country: They are not at 
all in command of the language in terms of grammar and spelling. But 
they can use the simple phrases to order a beer or buy a train ticket. 
That's all they need in most of the cases.

What I could imagine for this scenario is a very simple syntax, either 
using no namespace prefix at all or using a very obvious one like in 
"object/title" (even "context" is not that accessible -- you'll have to 
know in what context "context" is a context ... ;-)). To make things 
more explicit the application (e.g. a CMS) should have to explicitly 
expose the available attributes. This could be done using Interfaces 
and/or Schema definitions.

The cool thing about that would be that the available "API" could be 
explicitly exposed to the user, e.g. in the UI you could have a WYSIWYG 
editor widget with a drag&drop-enabled list of available variables. When 
accessing a ZPT over FTP we could add explicit variable declarations in 
the document head, like we expose the list of bound namespaces in 
Scripts (Python).

I think the problem with Zope 2 was that nobody clearly defined the 
target groups for things like DTML. So it was used for things it had not 
been designed for, like real scripting (in ZClasses). For content 
objects like File, Image, or HTML objects it makes sense to assume some 
basic set of properties, as Zope 2 implicitly does. On the other hand I 
agree that this should not be a requirement of the framework (i.e. Zope 
3). This requirement should be defined in the application, e.g. in the 
content object model of the CMS. Of course it makes sense to standardize 
this (probably using Dublin Core or other agreed-on metadata standards), 
but only in terms of defining an API for content objects, not as a 
requirement for objects to have (physical or computed) attributes of the 
names used.


b) The second scenario: Using ZPT as an application programmer to create 
templates for management interfaces etc.

Target group: Programmers with Python and (basic) Zope knowledge

This seems to work well already. But even in this scenario explicitly 
exposing the API would be very nice. Note that complex syntax is not a 
problem if you don't have to write it but just drag the variables or 
method names from an API browser into your code.

Cheers

Joachim