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

[Jim Fulton]

Evan Simpson wrote:
> Jim Fulton wrote:
> 
>>   context/dc:title
>>
>> which looks up the title api in the dc namespace for the object given
>> by the context.
> 
> [...]
> 
>> In Python code, we could do:
>>
>>   api(context).dc.title
> 
> 
> Why do you prefer this? 

To be honest, I prefer:

api(context).title

That was my original proposal.

Someone else suggested we needed a hierarchical napespace of APIs.
I suspect that this was motivated by the desire to use xml namespace
syntax.

 > I find it much easier to think in terms of
> accessing the 'title' property/attribute/whatever after applying the 
> 'dc' adapter.

If I was thinking in terms of adapters, I'd just create the adapter in the first
place. using Itamar's unimplemented syntax:

   IZopeDublinCore(context).title

>>    <api namespace="zope" name="title"
>>      for="zope.app.interfaces.annotation.IAnnotatable"
>>      factory="zope.app.dublincore.annotatableadapter.TitleAPI">
>>        title meta-data attribute
>>
>>        The title API attribute provides access to the (unqualified)
>>        Dublin-Core "Title" meta-data element.
>>    </api>
> 
> 
> Ack! We have to implement and declare a separate API for every single 
> meta-data attribute??

No, but we'd implement a declare an api for each api name.

>> Some people have suggested that namespaces are just adapters.
>> I think that this would be a bad idea as it would lead to very many
>> small namespaces.
> 
> 
> Only if there are a plethora of small APIs. 

But there *would* be a plethora of small apis if API === adapter.
Adapters implement individual interfaces.  I think that that is too
fine-grained for what we are talking about.

 > In the example above, I
> assumed that 'dc' is an adapter from IAnnotatable to an interface 
> (IAnnotationAccess?) that provides access to *all* of the Dublin Core 
> meta-data elements.

In the example I have, dc was just an API namespace. Later in my note,
I said I wouldn't actually use that. I'd use:

   context/api:title

or just:

   context/:title

Given arguments made elsewhere about how unsophisticated the audience
of this feature is, I wouldn't expect them to be thinking in terms of
adapters.

>> User's objected stenuously to including xml namespace declarations in
>> their zpts. We eventually, removed the necessity for declaring namespaces
>> in HTML zpts. I don't think requiring namspace declarations for API
>> functions would be popular.
> 
> 
> Part of the objection, I suspect, was that declaring TAL and METAL 
> namespaces was utter boilerplate.  At least in HTML templates, no one 
> cared about the ability to choose their own prefix, and the chances of a 
> prefix clash were essentially nil.  In XML namespace declarations are 
> quite common.
> 
> I imagine that allowing configurable pre-defined prefixes for undeclared 
> namespaces would be a good thing, especially for namespaces like the 
> Dublin Core that are built into Zope and widely used.

I would go much farther and have one namespace for standard apis
and let other app frameworks define additional api namspaces if they
want to.


 >  Cutting down the
> verbosity of the declaration would help, as well:
> 
>   tal:namespaces="dc zope:DublinCore"

Or eliminate it altogether. We don't declare expression types
or top-level variables.

> I'm not sure what value conflation with XML namespaces adds, given the 
> configurability of Zope 3.

I think it adds negative value.

...

>> Also note that this new syntax will be used in TALES outside of zpt.
>> For example, it would be useful to use these in simple stand-alone
>> TALES expressions where namespace declarations are inconventient or
>> impossible
> 
> 
> This would be another good argument for default prefixes. 

Right. Let's make all of the prefixes default. ;)

 > Also, we
> could allow expressions such as "object/zope.DublinCore:title" and 
> "widget/plone.FooBar:baz", i.e. the prefix can be the full name of the 
> adapter.

Except that this would be:

   object/zope.app.interfaces.dublincore.IZopeDublinCore/title

which wouldn't be that helpful.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org