Jim Fulton wrote:
I've posted two proposals:


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.


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  /  [EMAIL PROTECTED]  /  http://blog.ianbicking.org

Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to