RFC: TALES adapters and TAL/Tales variable namespaces
I've posted two proposals: http://dev.zope.org/Zope3/TALESPathExpressionAdapters 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. Comments are welcome, here or in the pages. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Wed, May 19, 2004 at 04:00:43PM -0400, Jim Fulton wrote:
I've posted two proposals:
http://dev.zope.org/Zope3/TALESPathExpressionAdapters
Proposes a mechanism for easily using adapters in TALES expressions.
Quick comment from over here in non-genius-land... -1 on the object*adapter notation. My brain is hardwired to see that as "object times adapter" and I just can't make sense of that ;-) +1 on the (adapter)object notation. It's a pretty good mnemonic, adapting is sorta like casting. The namespaces proposal looks fine to me, given that one believes it is necessary. Never occurred to me before :-) -- Paul Winkler http://www.slinkp.com
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.
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@colorstudy.com / http://blog.ianbicking.org
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
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:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
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
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:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
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
Jim Fulton wrote:
I've posted two proposals:
http://dev.zope.org/Zope3/TALESPathExpressionAdapters
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.
Based on initial comments, I've retracted ZPTVariableNamespaces and updated: http://dev.zope.org/Zope3/TALESPathExpressionAdapters I've thrown out a few more spellings for adapter use: ob->adaptername context->dc/title ob~adaptername context~dc/title ob[adaptername] context[dc]/title Of course, Steve suggested: ob:adaptername context:dc/title So far the cast syntax seems to be the most popular: (adaptername)ob (dc)context/title with one dissension. :) One disadvantage I see with the cast notation is that it's a bit jarring in: a/b/(adapter)c/d as the adapter is applied to a/b/c. The order just doesn't seem quite right. I'd love to get more feedback or suggestions for the syntax. As far as in-template definition, I'd like to borrow from Evan's work and allow 'adapter' to be used like 'local' or 'global' in tal:define: tal:define="adapter dc modules/zope.app.dublincore/IZopeDublinCore" Thoughts? Jim P.S. Thanks for all the comments so far. :) -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Friday 21 May 2004 09:07, Jim Fulton wrote:
So far the cast syntax seems to be the most popular:
(adaptername)ob (dc)context/title
Why don't we use adaptername(ob)? Then it looks exactely like in Python! Less to memorize. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Stephan Richter wrote:
On Friday 21 May 2004 09:07, Jim Fulton wrote:
So far the cast syntax seems to be the most popular:
(adaptername)ob (dc)context/title
Why don't we use adaptername(ob)? Then it looks exactely like in Python! Less to memorize.
Because that would be the top of a slippery slope. People would want: callable(arg1, arg2, arg3) eventually: foo/bar/callable(x/y, a/b/c)/q/r which is arguably the path to madness. A number of folks replid negatively to this idea when it was noted in the proposal. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Friday 21 May 2004 09:07, Jim Fulton wrote:
tal:define="adapter dc modules/zope.app.dublincore/IZopeDublinCore"
This looks very nice to me. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Jim Fulton wrote:
One disadvantage I see with the cast notation is that it's a bit jarring in:
a/b/(adapter)c/d
as the adapter is applied to a/b/c. The order just doesn't seem quite right.
That is indeed jarring, especially since c isn't an object, it's just a name, and a/b/c is the object in question. This would look somewhat better with the current : mechanism, like a/b/c:adapter/d My concern with this use of : was that it looked like it should be parsed like (a/b/c):(adapter/d), as opposed to ((a/b/c):adapter)/d -- maybe using something other than : wouldn't imply this grouping. Or maybe if I got used to it the grouping would seem more natural. I guess my intuition is that / binds more closely than : (even if there isn't any real precedence at all in TAL expressions). -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org
Ian Bicking wrote:
Jim Fulton wrote:
One disadvantage I see with the cast notation is that it's a bit jarring in:
a/b/(adapter)c/d
as the adapter is applied to a/b/c. The order just doesn't seem quite right.
That is indeed jarring, especially since c isn't an object, it's just a name, and a/b/c is the object in question. This would look somewhat better with the current : mechanism, like a/b/c:adapter/d
My concern with this use of : was that it looked like it should be parsed like (a/b/c):(adapter/d), as opposed to ((a/b/c):adapter)/d -- maybe using something other than : wouldn't imply this grouping. Or maybe if I got used to it the grouping would seem more natural. I guess my intuition is that / binds more closely than : (even if there isn't any real precedence at all in TAL expressions).
Yes, this is another issue. I have the same problem, somehow, with "foo/bar->dc/title". That is "/" seems to bind more closely than "->", probably because it's skinnier. :) I don't have this problem with ":". Another option is to modify the "/". For example, Evan sugested "/*", as in foo/bar/*dc/title Hm foo/:dc/title Sandly, nothing really jumps out as the best syntax. So far, I like: foo/bar->dc/title the best. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
| So far, I like: | | foo/bar->dc/title | | the best. OTOH, for 'valid' xhtml, u would have to write: foo/bar->>dc/title Totally defeating the purpose. One may argue that this would not be part of the output, but it breaks the editors (at least nxml-mode). -- Sidnei da Silva <sidnei@awkly.org> http://awkly.org - dreamcatching :: making your dreams come true http://www.enfoldsystems.com http://plone.org/about/team#dreamcatcher Linux - Where do you want to fly today? -- Unknown source
Sidnei da Silva wrote:
| So far, I like: | | foo/bar->dc/title | | the best.
OTOH, for 'valid' xhtml, u would have to write:
You mean well-formed.
foo/bar->dc/title
Totally defeating the purpose. One may argue that this would not be part of the output, but it breaks the editors (at least nxml-mode).
Wrong. Double check the spec. (I did. :) http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-AttValue You only need to escape the less-than because there's no way to mistake "a->b" as a tag. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
| You mean well-formed. Right. | Wrong. Double check the spec. (I did. :) | | http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-AttValue | | You only need to escape the less-than because there's no way to | mistake "a->b" as a tag. Beats me :) -- Sidnei da Silva <sidnei@awkly.org> http://awkly.org - dreamcatching :: making your dreams come true http://www.enfoldsystems.com http://plone.org/about/team#dreamcatcher Those who don't understand Linux are doomed to reinvent it, poorly. -- unidentified source
Jim Fulton wrote:
Sidnei da Silva wrote:
| So far, I like: | | foo/bar->dc/title | | the best.
OTOH, for 'valid' xhtml, u would have to write:
You mean well-formed.
foo/bar->dc/title
Totally defeating the purpose. One may argue that this would not be part of the output, but it breaks the editors (at least nxml-mode).
Wrong. Double check the spec. (I did. :)
http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-AttValue
You only need to escape the less-than because there's no way to mistake "a->b" as a tag.
xmllint (from libxml2) doesn't think the '>' is legitimate:: [/home/tseaver] $ cat > test.xml <?xml version="1.0"?> <test attribute="foo > bar" /> [/home/tseaver] $ xmllint test.xml <?xml version="1.0"?> <test attribute="foo > bar"/> I would be reluctant to duel with Daniel using my XML language lawyer chops. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Tres Seaver wrote:
Jim Fulton wrote:
Sidnei da Silva wrote:
| So far, I like: | | foo/bar->dc/title | | the best.
OTOH, for 'valid' xhtml, u would have to write:
You mean well-formed.
foo/bar->dc/title
Totally defeating the purpose. One may argue that this would not be part of the output, but it breaks the editors (at least nxml-mode).
Wrong. Double check the spec. (I did. :)
http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-AttValue
You only need to escape the less-than because there's no way to mistake "a->b" as a tag.
xmllint (from libxml2) doesn't think the '>' is legitimate::
[/home/tseaver] $ cat > test.xml <?xml version="1.0"?> <test attribute="foo > bar" /> [/home/tseaver] $ xmllint test.xml <?xml version="1.0"?> <test attribute="foo > bar"/>
Pehaps, in the tradition of lint programs, it's being conservative.
I would be reluctant to duel with Daniel using my XML language lawyer chops.
The spec is pretty clear. But, if tools are going to be confused by this, we should avoid it. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
One disadvantage I see with the cast notation is that it's a bit jarring in:
a/b/(adapter)c/d
as the adapter is applied to a/b/c. The order just doesn't seem quite right.
Unless I'm misunderstanding something fundamental here, in the TALES context an adapter is essentially a function accepting a single argument. The "adapted" object that results from applying the adapter function is either used directly or further traversed. All of the other qualities that make up an Adapter (how it's registered, that it supports ITALESAdapter, etc.) are irrelevant to its use in a TALES expression. Given all that, why do we need to shoehorn the adapter's name into the same path segment as one of the traversal names? The above looks much more natural to me as one of: a/b/c/(adapter)/d a/b/c/*adapter/d a/b/c/adapter()/d a/b/c/adapter:/d Note that the latter two forms allow for additional arguments. While not applicable to single-argument adapters, this is certainly a useful feature if we don't restrict the syntax to adapters only. In particular, evan-pathprefix-branch uses the colon syntax to allow applications such as "a/b/c/index:2/d" and "a/b/c/call:x,y/d". This same scheme can easily subsume adapters in either or both of two ways: adapter as prefix, and adapter name as argument to a prefix. tal:define="prefix foobar adapter:foo.bar" tal:content="a/b/c/foobar:/d" ...or... tal:define="prefix A builtin:adapters" tal:content="a/b/c/A:foo.bar/d" Cheers, Evan @ 4-am
Evan Simpson wrote:
Jim Fulton wrote:
...
Unless I'm misunderstanding something fundamental here, in the TALES context an adapter is essentially a function accepting a single argument.
Yes, except s/function/callable
The "adapted" object that results from applying the adapter function is either used directly or further traversed. All of the other qualities that make up an Adapter (how it's registered, that it supports ITALESAdapter, etc.) are irrelevant to its use in a TALES expression.
Yes, except that systems will define some predefined standard adapters for providing common tasks, like formatting or meta-data access.
Given all that, why do we need to shoehorn the adapter's name into the same path segment as one of the traversal names?
We don't. In fact, one could argue that adaptation is a bit like a different kind of traversal. In fact, in Zope 3, we already have a notion of this. In general, in Zope 3 paths, we can say: foo/++namespace++name where "/++namespace++" can be thought of as a special form of namespace operator (similar and partly inspired by xpaths "/:namespace:"). So, we could also use something like: content/++adapter++dc/title but I think people want something more concide for ZPT. I should point out that this has special importance for Zope 3 because Zope3 content objects don't provide any standard APIs. You generally have to apply adapters to them to get at any standard apis.
The above looks much more natural to me as one of:
a/b/c/(adapter)/d a/b/c/*adapter/d a/b/c/adapter()/d a/b/c/adapter:/d
Let me make these more concrete: context/(dc)/title context/*dc/title context/dc()/title context/dc:/title IMO, if we take this route, we should think of the notation as providing an alternate traversal operator. That is, there is syntax that either modifies or replaces "/", so of the examples above, only: context/*dc/title works for me. For me: context->dc/title can be read the same way. Basically, '->', is just a different traversal operator. FWIW, I find this more "natural" than any of your examples. Of course, naturalness is highly subjective.
Note that the latter two forms allow for additional arguments. While not applicable to single-argument adapters, this is certainly a useful feature if we don't restrict the syntax to adapters only. In particular, evan-pathprefix-branch uses the colon syntax to allow applications such as "a/b/c/index:2/d" and "a/b/c/call:x,y/d". This same scheme can easily subsume adapters in either or both of two ways: adapter as prefix, and adapter name as argument to a prefix.
tal:define="prefix foobar adapter:foo.bar" tal:content="a/b/c/foobar:/d"
...or...
tal:define="prefix A builtin:adapters" tal:content="a/b/c/A:foo.bar/d"
I find I have to think waaaay to hard about what's going on in these examples. In particular, in the above excample, "A" is working on both "a/b/c" and "foo.bar". Basically, there is an extra level of indirection. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
IMO, if we take this route, we should think of the notation as providing an alternate traversal operator. That is, there is syntax that either modifies or replaces "/", so of the examples above, only:
context/*dc/title
In that case, I'd be happy to consider adaptation as orthogonal to my path prefixes. Might as well drop the slash and go with the previous suggestion: context*dc/title I can easily read the star as an adaptation operator, even with multiple applications. Cheers, Evan
Evan Simpson wrote:
Jim Fulton wrote:
IMO, if we take this route, we should think of the notation as providing an alternate traversal operator. That is, there is syntax that either modifies or replaces "/", so of the examples above, only:
context/*dc/title
In that case, I'd be happy to consider adaptation as orthogonal to my path prefixes.
Yup.
Might as well drop the slash and go with the previous suggestion:
context*dc/title
I can easily read the star as an adaptation operator, even with multiple applications.
On IRC, Martijn Faassen suggested (brainstormed really :) '#', as in: context#dc/title I like this becase # kinda looks like a special kind of slash. :) What do people think of this? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
Evan Simpson wrote:
Jim Fulton wrote:
IMO, if we take this route, we should think of the notation as providing an alternate traversal operator. That is, there is syntax that either modifies or replaces "/", so of the examples above, only:
context/*dc/title
In that case, I'd be happy to consider adaptation as orthogonal to my path prefixes.
Yup.
Might as well drop the slash and go with the previous
suggestion:
context*dc/title
I can easily read the star as an adaptation operator, even with multiple applications.
On IRC, Martijn Faassen suggested (brainstormed really :) '#', as in:
context#dc/title
I like this becase # kinda looks like a special kind of slash. :)
Hm, special kind of slash ... what about context\dc/title Tonico (Not yet a Python developer.)
On Thu, May 27, 2004 at 10:00:50PM +0200, Tonico Strasser wrote:
Jim Fulton wrote:
On IRC, Martijn Faassen suggested (brainstormed really :) '#', as in:
context#dc/title
I like this becase # kinda looks like a special kind of slash. :)
Looks ok to me.
Hm, special kind of slash ... what about
context\dc/title
-1. I see \d and automatically read it as "escape d". -- Paul Winkler http://www.slinkp.com
Jim Fulton wrote:
We don't. In fact, one could argue that adaptation is a bit like a different kind of traversal. In fact, in Zope 3, we already have a notion of this. In general, in Zope 3 paths, we can say:
foo/++namespace++name
where "/++namespace++" can be thought of as a special form of namespace operator (similar and partly inspired by xpaths "/:namespace:").
So, we could also use something like:
content/++adapter++dc/title
but I think people want something more concide for ZPT.
I prefer this notation, even though it's more verbose. I think it should be supported along with a short cut syntax. This problem seems analogous to view lookup -- "content/++view++index.html" and "content/@@index.html" are equivalent. So, applied to adapters, we could use: content/++adapter++dc/title (or '++adapt++') one could use: content/##dc/title or perhaps (yuckier): content/**dc/title I'd hate to see Yet Another Traversal Syntax introduced when we already have a decent pattern established. -- Garrett
On Thu, May 27, 2004 at 03:55:23PM -0500, Garrett Smith wrote:
So, we could also use something like:
content/++adapter++dc/title
but I think people want something more concide for ZPT.
I prefer this notation, even though it's more verbose. I think it should be supported along with a short cut syntax.
This problem seems analogous to view lookup -- "content/++view++index.html" and "content/@@index.html" are equivalent.
So, applied to adapters, we could use:
content/++adapter++dc/title (or '++adapt++')
one could use:
content/##dc/title
or perhaps (yuckier):
content/**dc/title
I'd hate to see Yet Another Traversal Syntax introduced when we already have a decent pattern established.
I like this train of thought. Today I brainstormed content/::dc/title on IRC. I'm not entirely sure why, but adaptation and the ':' character seem to be related in my mind. Marius Gedminas -- Never be afraid to tell the world who you are. -- Anonymous
I want to thank everyone who's participating in this thread. The input is extremely valuable. Garrett Smith wrote:
Jim Fulton wrote:
We don't. In fact, one could argue that adaptation is a bit like a different kind of traversal. In fact, in Zope 3, we already have a notion of this. In general, in Zope 3 paths, we can say:
foo/++namespace++name
where "/++namespace++" can be thought of as a special form of namespace operator (similar and partly inspired by xpaths "/:namespace:").
So, we could also use something like:
content/++adapter++dc/title
but I think people want something more concide for ZPT.
I prefer this notation, even though it's more verbose. I think it should be supported along with a short cut syntax.
This problem seems analogous to view lookup -- "content/++view++index.html" and "content/@@index.html" are equivalent.
So, applied to adapters, we could use:
content/++adapter++dc/title (or '++adapt++')
one could use:
content/##dc/title
or perhaps (yuckier):
content/**dc/title
I'd hate to see Yet Another Traversal Syntax introduced
Too late. :) Path expressions already introduce separate syntax. This is, in part, to take advantage of the TALES variable namespaces, which aren't relevent to generic path traversal.
when we already have a decent pattern established.
We are talking about two different systems here. The ++namespace++name syntax is part of Zope's generic path execution machinery, which Zope 3 TALES uses. When we use this syntax, or @@name. all of the work is done by the namespace machinery, not by TALES. This means that TALES has no control over it. So, if you rely solely on the standard traversal machinery, you won't be able to define short names within the template. I suggest that whatever short syntax we come up with should be handled by TALES, not the standard path traversal machinery. Given that, I still prefer context#dc to context/##dc. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
Given that, I still prefer context#dc to context/##dc.
+1 I like the idea that '/' and '#' are both path separators, and that the semantics of each path segment depend on the preceding separator. Cheers, Evan
I've updated http://dev.zope.org/Zope3/TALESPathExpressionAdapters based on comments to date. I think we are narrowing down on a short syntx of the form: ob/##adaptername where '#' is some character. See the proposal for reasons. I've also given the current status there. Jim Jim Fulton 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.
http://dev.zope.org/Zope3/ZPTVariableNamespaces
proposes a mechanism for qualifying names defined in TAL and used in TALES expressions.
Based on initial comments, I've retracted ZPTVariableNamespaces and updated:
http://dev.zope.org/Zope3/TALESPathExpressionAdapters
I've thrown out a few more spellings for adapter use:
ob->adaptername context->dc/title
ob~adaptername context~dc/title
ob[adaptername] context[dc]/title
Of course, Steve suggested:
ob:adaptername context:dc/title
So far the cast syntax seems to be the most popular:
(adaptername)ob (dc)context/title
with one dissension. :)
One disadvantage I see with the cast notation is that it's a bit jarring in:
a/b/(adapter)c/d
as the adapter is applied to a/b/c. The order just doesn't seem quite right.
I'd love to get more feedback or suggestions for the syntax.
As far as in-template definition, I'd like to borrow from Evan's work and allow 'adapter' to be used like 'local' or 'global' in tal:define:
tal:define="adapter dc modules/zope.app.dublincore/IZopeDublinCore"
Thoughts?
Jim
P.S. Thanks for all the comments so far. :)
-- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
participants (11)
-
Evan Simpson -
Garrett Smith -
Gary Poster -
Ian Bicking -
Jim Fulton -
Marius Gedminas -
Paul Winkler -
Sidnei da Silva -
Stephan Richter -
Tonico Strasser -
Tres Seaver