[ZPT] RFC: TALES adapters and TAL/Tales variable namespaces

[Ian Bicking]

Jim Fulton wrote:
> I've posted two proposals:
> 
>   http://dev.zope.org/Zope3/TALESPathExpressionAdapters

Not much opinion.  Though I fear that "(adapter)object" could lead to 
this syntax in Python itself, which would be horrid ;)  I agree that 
adapter(object) is a bad direction.  object*adapter looks fine to me, 
and it seems reasonable that only a specific set of adapters would be 
available in TAL expressions (i.e., adapters which provide ITALESAdapter).

> Proposes a mechanism for easily using adapters in TALES expressions.
> 
>   http://dev.zope.org/Zope3/ZPTVariableNamespaces
> 
> proposes a mechanism for qualifying names defined in TAL and used in
> TALES expressions.

I'm suspicious of namespaces, as they seem redundant.  Namespaces in 
Python, after all, are expressed like any other attribute traversal 
(e.g., os.path.exists).  The analog in TAL would be adapter/foo.  This 
is how TAL works right now in practice, with a small number of 
namespaces like request, container, etc.

I see a few problems with the current situation:

1. There's no clear way to indicate that you want to use a name as a 
namespace, as opposed to a normal name.  So there may be a conflict 
between the "adapter" you want to use as a namespace, and a template 
that someone writes that happens to use the variable adapter in an 
unrelated way.  This is fine now, because there is a fairly fixed number 
of namespaces (six or seven, I think), and you just don't use those 
names -- as namespaces are added (especially on a per-metal-template 
basis) this conflict is more likely, and you may not know what names 
will cause conflicts in the future.

But I'm not sure how bad the name conflict really is.  In my experience 
it's not too bad in Python code, and when it's a problem it's fairly 
easily resolved.  Or maybe another one or two namespaces can be added 
which would sufficient, and we don't need to extend the number of 
namespaces indefinitely.  Like an adapter namespace and a metal 
namespace (maybe you'd use things like 
metal/name_of_template.pt/variable_name).  To some degree this could 
even be convention, instead of building it in explicitly.

2. Another issue might be the difficulty of creating a namespace for use 
with templates -- with the proposal all namespaces start out empty and 
ready to accept new values, but if you use normal variables they start 
out as undefined, and you'd have to assign them to {} or something.

(A little thought: if you had "def namespace(): return {}", then 
tal:define="adapter namespace" would work and reads fairly well)

3. Explicit namespaces support deeper, structured assignment (but only a 
*little* deeper).  Does TAL currently allow tal:define="var/attr 
something"?  I've never tried it.  It should.  Maybe the specific 
semantics of this assignment could be refined to resolve (2) -- e.g., if 
you get a LookupError during the second-to-last segment of the 
traversal, try to assign it to {}.

Anyway, whenever I look at a language with explicit namespaces (e.g., 
Ruby), it seems really pointless.  I think they should be avoided, and 
that normal TAL path expressions can be refined instead.

It's also annoying that we'd have namespace['adapter'] in Python 
expressions.  Namespaces might be a way to introduce a more accessible 
set of typical functions, like DTML's nl2br and other formatting 
functions -- these are currently too hard to get to.  But these have to 
be used with Python syntax (at least currently), and doing 
namespace['formatters']['nl2br'](options['message']) is just bad.  I 
don't much care for tal:define="nl2br formatters:nl2br" either, as it 
feels like boilerplate.  I suppose 
"path('formatters:nl2br')(path('options/message')) is maybe a little 
better, but only a very little.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org