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:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://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 )
