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

[Shane Hathaway]

On Thu, 27 Feb 2003, Tres Seaver wrote:

> On Thu, 2003-02-27 at 08:53, Shane Hathaway wrote:
> > Default prefixes are good for two cases that I can think of: common
> > minimal presentation operations that are currently difficult to write but
> > shouldn't be (and shouldn't require any Python), and access to core Zope
> > APIs (to make writing templates easy in Zope).  There's no conflict in
> > those cases and the default prefixes would be a service to all template
> > authors.
> 
> Maybe I'm just being dense, but can't we solve the "default namespaces"
> issue by defining the defaults in the 'main_template', in which *every*
> "normal" Zope page template will wrap itself?  Then people who want to
> re-bind the defaults, or add new ones, will just customize that template
> (or the macro which defines the namespaces :).

Like Fred said, binding prefixes to namespace URIs should happen when the
template is compiled, so macros are too late.

The question is still whether prefixes get mapped to namespaces or
directly to components.  I wouldn't debate this if I didn't think Jim had
a really good point: if namespace URIs aren't involved and not even
possible, people who don't know XML namespaces will have less to learn and
ZCML doesn't need to become aware of URIs.  TALES expressions used outside
TAL would have full access to all namespaces.  And template maintainers
would always know, without scanning for "talns" attributes, that the "dc"
prefix maps to Dublin Core.

A good compromise is to set up default prefix to URI mappings in ZCML.  
If we use namespace URIs and set up some default prefixes, we'll address
two of the four issues I've been able to identify: new Zope users won't
have to declare namespaces, and TALES expressions used outside TAL will
have access to the default prefixes.  But ZCML will still have to become
aware of URIs, although since that only affects developers, it might be
only an inconvenience.

The remaining issue is that prefixes may have different meanings in
different templates, so template maintainers have to pay careful attention
to "talns" attributes.  But that's a reality we already face in page
templates, XML, and Python, and the usual solution is to use unenforced
conventions, like never mapping the "tal" prefix to something other than 
the TAL URI.  So far, this strategy has worked well.

Shane