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

[Tres Seaver]

On Sun, 2003-02-23 at 18:40, Stuart Bishop wrote:

> On Monday, February 24, 2003, at 01:23  AM, Jim Fulton wrote:
> 
> >   context/++view++foo
> >   context/@@foo
> >   context/++api++title
> >   context//title
> >   context/++/title
> >
> > Thoughts?
> 
> 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"/>

+1, given that we can control the amount of "majyk" which happens.  This
maps fairly well onto the kind of namespacey stuff people see with
things like RSS.  For instance, here is the top-level element for an
RSS template I just wrote this weekend::

 <?xml version="1.0"?>

 <rdf:RDF 
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:syn="http://purl.org/rss/1.0/modules/syndication/"
   xmlns:rss="http://purl.org/rss/1.0/"
   tal:define="info_items view/listSyndicationInfo" >

  <rss:channel rdf:about="CONTEXT_URL"
               tal:attributes="rdf:about
                 string:${view/context_url}/index.rss;" >

   <rss:title tal:content="view/dc/title">BLOG TITLE</rss:title>

Defining your namespaces at the top is at least a notion people will
have seen elsewhere.  Note that, in this example, I had to define the
'dc' name as an attribute of my view class::

  class MyView:

      __used_for__ = IMyContainer

      def __init__(self, context, request):

          self.context = context
          self.request = request
          self.adapted = getAdapter(context, IMyContainer)
          self.dc = getAdapter( context, IZopeDublinCore )
          self.context_url = getView(context, 'absolute_url',
                                     request)()

If we had a way to define the 'dc' bit early in the template, (e.g., in
the "prologue"), and if the typical ones used by template authors were
defined by default in the standard template, then people could re-wire
them by changing the template.

OTOH, these "special" names, like slot names, will become part of the
not-well-documented API for template writers:  today, in the CMF, 
changing the particular slots names used  breaks *lots* of third-party
templates, which is a weakness of the "implicit" API.

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

Avoiding the need to use '@@' or '++' yourself is already pretty easy
for two common cases:  "leaf" content objects don't have an "items"
namespace, and therefore don't need to distinguish views from sub-items,
while id-generating containers can control the "items" namespace to
avoid the clash.  The only hard case is, unfortunately, very common: 
containers which allow user-entered IDs can't reliably distinguish
between sub-items and software without the help of the prefixes.  Fixing
that problem (which has been the source of *lots* of grief for
new-to-Zope programmers) was a major goal for Zope3.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com