[Zope3-dev] Re: Better access to APIs in paths

Mon, 24 Feb 2003 11:17:00 -0500

Joachim Werner wrote:
>>> 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.

I agree whole-heartedly on this!  Even if the weird syntax made sense
upon investigation, it just looks so foreign that people will be
frightened off.

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

Personally, I found the ZPT Built-in Names to be very understandable,
meaningful, and useful.  I never perceived them as an inconvenient
necessity (as Joachim seems to infer).

[...]
> 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 one syntax that seemed recognizable (and thus least frightening) to 
me as a Zope 2 ZPT user was the one suggested by Stuart Bishop.

Stuart Bishop wrote:
> For ZPT (which I think deserves a special case because of its target 
> audience): 

 > <h1 tal:content="dc:context/title"/>
 >   or for a shortcut to the most common case, just
 > <h1 tal:content="dc:title"/>

> Will be more familiar and explainable. API -> prefix mappings
> specified in the config files, and can be overridden by properties on
> the page template object (or possibly with a new <html tal:ns="dc
> IZopeDublinCore"> TAL tag.

Yes, please hide this from me in the config files.

> This approach could also be used to make access from Python Scripts
> more mnemonic using these prefixes, but I think
> IZopeDublinCore(ob).title is quite acceptable. dc(ob).title would
> probably be the best alternative.

If I had to write "IZopeDublinCore(ob).title" in my work, I'd think 
about quitting.  Could anything be more obscure to the 
non-Zope-developer than a reference to Dublin?

> This all doesn't match the subject of this thread, but I think using 
> a 'generic-works-everywhere' path syntax (limited by what can go in a
> URL) in places where there is more flexibilty will lead to much
> yuckyness and desires to stick with Zope 2. A good goal would be to
> make understanding the magic Perlish syntax a requirement of as few
> Actors as possible IMHO. Preferably none at all, with any '++@@'
> gibberish being generated by Zope or helper methods. I know I'd be
> turned off if I saw this sort of thing in a 'Hello World' equivalent.

Plus Ten from me.

Jon Whitener
Detroit Michigan USA