Re: [Zope-dev] Re: [Zope3-dev] Re: [ZPT] Re: RFC: TALES adapters and TAL/Tales variable namespaces
| 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 <[EMAIL PROTECTED]> 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 ___ 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 )
Re: [Zope-dev] Re: [Zope3-dev] Re: [ZPT] Re: RFC: TALES adapters and TAL/Tales variable namespaces
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:[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 )
Re: [Zope-dev] Re: [Zope3-dev] Re: [ZPT] Re: RFC: TALES adapters and TAL/Tales variable namespaces
| 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 <[EMAIL PROTECTED]> 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 ___ 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: [Zope3-dev] Re: [ZPT] Re: RFC: TALES adapters and TAL/Tales variable namespaces
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:[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: [Zope3-dev] Re: [ZPT] Re: RFC: TALES adapters and TAL/Tales variable namespaces
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 wy 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-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 )
