[Zope-dev] Re: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces
Evan Simpson wrote: Jim Fulton wrote: I've posted two proposals: http://dev.zope.org/Zope3/TALESPathExpressionAdapters Proposes a mechanism for easily using adapters in TALES expressions. I'm not at all clear on how the proposed mechanism is superior to the implementation of path segment prefixes that exists in Zope 2. This differs from the namespace proposal that you cite, in that the object named on the left of the colon is not a namespace or adapter. It is simply a registered name that is associated with code that interprets the text to the right of the colon. This allows constuctions such as a/sequence/index:2 (a.sequence[2]), a/bag/var:x/call: (a.bag[x]()), and an/object/adapt:foo.bar (foo.bar(an.object)). I thought you had proposed this, but I couldn't find a proposal or documentation. You say this is implemented in Zope 2? Where is it documented? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces
Jim Fulton wrote: I thought you had proposed this, but I couldn't find a proposal or documentation. You say this is implemented in Zope 2? Where is it documented? Actually, it's only implemented on evan-pathprefix-branch. It has been quite a while since I had a chance to work on it, so I had forgotten that it was never merged, or properly documented for that matter. Pretty much all the information about it that isn't in the source code is in the ZPT list archives from August and September (e.g. http://mail.zope.org/pipermail/zpt/2003-August/004902.html) So, no worries if you decide to take a completely different direction -- it was never released. Cheers, Evan ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces
Evan Simpson wrote: Jim Fulton wrote: I thought you had proposed this, but I couldn't find a proposal or documentation. You say this is implemented in Zope 2? Where is it documented? Actually, it's only implemented on evan-pathprefix-branch. It has been quite a while since I had a chance to work on it, so I had forgotten that it was never merged, or properly documented for that matter. Pretty much all the information about it that isn't in the source code is in the ZPT list archives from August and September (e.g. http://mail.zope.org/pipermail/zpt/2003-August/004902.html) Thanks for the pointer. So, no worries if you decide to take a completely different direction -- it was never released. I had forgotten that there was already a notion of namespaces (local and global) and a syntax for defining variables in those namespaces. This is very helpful. So, we could define an adapter or prefix namespace without providing a generalizd namespace mechanism. I don't inderstand what motivated the special expression types for this namespace. For example, to get at file-system based code, couldn't you have used the modules variable? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces
Jim Fulton wrote: I don't inderstand what motivated the special expression types for this namespace. For example, to get at file-system based code, couldn't you have used the modules variable? I started there, but went with the special expression types because the set of things that are valid to define as prefixes is completely disjoint from those that you would use in other TAL statements. I've grown wary of tying abstract object names to Python package and module structure. Also, while I find it difficult to describe precisely, I have a strong intuition that arbitrary objects should not be available for use as prefixes. Of course, the idea of prefixes as Zope 3 adapters intead of custom-made prefix implementations may change things. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces
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 / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces
Jim Fulton wrote: I've posted two proposals: http://dev.zope.org/Zope3/TALESPathExpressionAdapters Proposes a mechanism for easily using adapters in TALES expressions. I'm not at all clear on how the proposed mechanism is superior to the implementation of path segment prefixes that exists in Zope 2. This differs from the namespace proposal that you cite, in that the object named on the left of the colon is not a namespace or adapter. It is simply a registered name that is associated with code that interprets the text to the right of the colon. This allows constuctions such as a/sequence/index:2 (a.sequence[2]), a/bag/var:x/call: (a.bag[x]()), and an/object/adapt:foo.bar (foo.bar(an.object)). http://dev.zope.org/Zope3/ZPTVariableNamespaces proposes a mechanism for qualifying names defined in TAL and used in TALES expressions. This would of course conflict with prefixes as currently defined, and seems weakly motivated. I can imagine getting a similar effect with a more consistent syntax by allowing tal:define=x/y foo when x supports an ITALESNamespace interface. The path x/y/z then does exactly what the user would expect. A namespace x can be created without any new TAL syntax by providing a built-in constructor, as in tal:define=x namespace, that creates an empty dictionary-like object with support with ITALESNamespace. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
