During the Melbourne Zope3 Sprint, someone ran up against a situation where they'd have liked to have TALES perform a tuple unpacking like Python can. I've just run into a similar situation :) Say a method listFilesByUser returns a list of (user, [files]) it'd be nice to be able to:: tal:repeat="user,files here/listFilesByUser" or similar. Currently we would have to use a python: expression to manually unpack the tuple. Kinda yucky. Any comments? Richard
On Wed, Jul 23, 2003 at 03:59:58PM +1000, Richard Jones wrote:
Say a method listFilesByUser returns a list of (user, [files]) it'd be nice to > be able to::
tal:repeat="user,files here/listFilesByUser"
or similar. Currently we would have to use a python: expression to manually unpack the tuple. Kinda yucky.
Any comments?
hmm... so you want to extend the language so you can write: <span tal:repeat="user,files here/listFilesPerUser"> <div tal:content="user"> user goes here </div> <div tal:repeat="file files" tal:content="file"> file goes here </div> </span> I disagree... There's probably a million little things that "would be nice" in ZPT. Rather than feature-creep TAL/TALES, which are pretty simple currently, let's leave the heavy lifting to our favorite tried-and-true general-purpose language. In this case, consider a trivial change to (or wrapper around) listFilesByUser to make it return a sequence of dictionaries like {'user': some_user, 'files': (file1, file2...)} Then your zpt could look like: <span tal:repeat="fpu here/listFilesPerUser"> <div tal:content="fpu/user"> user goes here </div> <div tal:repeat="file fpu/files" tal:content="file"> file goes here </div> </span> -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's TWINKLY-GIANT WOMAN! (random hero from isometric.spaceninja.com)
Paul Winkler writes:
In this case, consider a trivial change to (or wrapper around) listFilesByUser to make it return a sequence of dictionaries like {'user': some_user, 'files': (file1, file2...)}
This is exactly what the proposal I posted a couple of weeks ago was trying to avoid. While adding another layer of indirection around the actual call to listFilesByUser() isn't all that costly, these things add up, especially since so many temporary objects are getting created and thrown away. I know for Zope 3, we'd like to get away from having to write a view class simply to hook up helpers like this when something simpler would do. So far, two distinct approaches have been presented, with minor variations for each. I won't go into the variations, but the two approaches are: - Use a Python-like sequence unpacking syntax. This is probably most comfortable to template authors who are Python programmers first, and web guys (or gals!) second. - Use the namespace qualifiers to get an adapter to handle converting container lookup to a sequence indexing operation. This plays off the machinery being built anyway, so is quite attractive, and doesn't affect the basic syntax or implementation of TAL, but only of the TALES expression engine. This is very attractive because it pushes the support for this feature somewhere the application controls in as much detail as it wants. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
Fred L. Drake, Jr. wrote:
- Use a Python-like sequence unpacking syntax. This is probably most comfortable to template authors who are Python programmers first, and web guys (or gals!) second.
-0 for feature creap
- Use the namespace qualifiers to get an adapter to handle converting container lookup to a sequence indexing operation. This plays off the machinery being built anyway, so is quite attractive, and doesn't affect the basic syntax or implementation of TAL, but only of the TALES expression engine. This is very attractive because it pushes the support for this feature somewhere the application controls in as much detail as it wants.
+1 'cos I like the way this leverages the stuf we added to TALES at the last UK sprint... cheers, Chris
Say a method listFilesByUser returns a list of (user, [files]) it'd be nice to be able to::
tal:repeat="user,files here/listFilesByUser"
or similar. Currently we would have to use a python: expression to manually unpack the tuple. Kinda yucky.
yeah, or make listFilesByUser return {'username': user, 'files': files} and:: <tal:x repeat="user_dict here/listFilesByUser"> <tal:y define="user user_dict/username; files user_dict/files" /> </tal:x> also not ideal. I think the format in your example works well. -- Jean Jordaan http://www.upfrontsystems.co.za
Richard Jones wrote:
During the Melbourne Zope3 Sprint, someone ran up against a situation where they'd have liked to have TALES perform a tuple unpacking like Python can. I've just run into a similar situation :)
Say a method listFilesByUser returns a list of (user, [files]) it'd be nice to be able to::
tal:repeat="user,files here/listFilesByUser"
or similar. Currently we would have to use a python: expression to manually unpack the tuple. Kinda yucky.
I agree that it is 'yucky', but I have to disagree with your proposed solution. I would rather suggest making TALES aware of integer indexes for sequences. Example:: <tal:block repeat="user_files here/listFilesByUser"> User: <tal:dummy replace="user_files/0" /> File: <tal:dummy replace="user_files/1" /> </tal:block> Regards, Phil
Philipp von Weitershausen wrote:
I agree that it is 'yucky', but I have to disagree with your proposed solution. I would rather suggest making TALES aware of integer indexes for sequences. Example::
<tal:block repeat="user_files here/listFilesByUser"> User: <tal:dummy replace="user_files/0" /> File: <tal:dummy replace="user_files/1" /> </tal:block>
Here's the way I'd like to spell it: <div tal:repeat="user_files here/listFilesByUser"> User: <span tal:replace="user_files/int:0" /> File: <span tal:replace="user_files/int:1" /> </div> Literally, "user_files/int:0" says "get item 0 of user_files, interpreting '0' as an integer". Technically, this could be interpreted as "get the attribute named 0 or item 0", but an attribute name must be a string, so implicitly it really just says "get item 0". We've come up with a number of generally useful prefixes, BTW. Off the top of my head: call: -- Call a named method int: -- Look up an item by index format: -- Perform simple formatting operations like "format:money" zope: -- Access a big Zope API It sure would be nice to have these prefixes, both in Zope 2 and Zope 3. Shane
Shane Hathaway wrote:
Philipp von Weitershausen wrote:
I agree that it is 'yucky', but I have to disagree with your proposed solution. I would rather suggest making TALES aware of integer indexes for sequences. Example::
<tal:block repeat="user_files here/listFilesByUser"> User: <tal:dummy replace="user_files/0" /> File: <tal:dummy replace="user_files/1" /> </tal:block>
Here's the way I'd like to spell it:
<div tal:repeat="user_files here/listFilesByUser"> User: <span tal:replace="user_files/int:0" /> File: <span tal:replace="user_files/int:1" /> </div>
Literally, "user_files/int:0" says "get item 0 of user_files, interpreting '0' as an integer". Technically, this could be interpreted as "get the attribute named 0 or item 0", but an attribute name must be a string, so implicitly it really just says "get item 0".
We've come up with a number of generally useful prefixes, BTW. Off the top of my head:
call: -- Call a named method int: -- Look up an item by index format: -- Perform simple formatting operations like "format:money" zope: -- Access a big Zope API
It sure would be nice to have these prefixes, both in Zope 2 and Zope 3.
Hm. But then would we not be better of using python: expressions in the first place? Seems to save a lot of typing. I'd better like to build up lazy complex objects with python scripts to pass to ZPT, I think this would make more sense. Imagine instead of returning lists of dictionaries with all precalculated values you return list of objects with real methods to calculate attributes on demand. (Yes, sounds like ZPatterns, but may be a more easy interface) Regards Tino
Tino Wildenhain wrote:
Shane Hathaway wrote:
We've come up with a number of generally useful prefixes, BTW. Off the top of my head:
call: -- Call a named method int: -- Look up an item by index format: -- Perform simple formatting operations like "format:money" zope: -- Access a big Zope API
It sure would be nice to have these prefixes, both in Zope 2 and Zope 3.
Hm. But then would we not be better of using python: expressions in the first place? Seems to save a lot of typing.
How is it less typing to write a Python expression?
I'd better like to build up lazy complex objects with python scripts to pass to ZPT, I think this would make more sense.
Think of prefixes as site-wide, generally useful Python scripts. Quite often some API returns something that's intuitively easy to present, but ZPT's syntax makes it somewhat difficult to present. For example, it should not be necessary to write a Python script or expression every time you want to format the number 5 as "$5.00". Shane
On Wed, Jul 23, 2003 at 10:48:10AM -0400, Shane Hathaway wrote:
Think of prefixes as site-wide, generally useful Python scripts.
That's fine and dandy... but please please PLEASE don't let that be the only way to call them. Put them in ZTUtils, or Products.PythonScripts.standard, or someplace generally available. What bothers me is the tendency in z2 to improve one tool with little features that would be "nice to have", adding functionality that is either not provided elsewhere, or is provided elsewhere in a totally different way. So please, if there's new functionality you want to add, consider: how would I use this functionality from a script? from dtml? from a product?
Quite often some API returns something that's intuitively easy to present, but ZPT's syntax makes it somewhat difficult to present. For example, it should not be necessary to write a Python script or expression every time you want to format the number 5 as "$5.00".
No script needed, and I *like* that zpt encourages python expressions. Makes it easy to refactor things out into Scripts when you realize that your page template is doing too much work. In this case, the expression you need is documented (although it really needs an explicit example) in the Zope Book, API Reference: <span tal:define="pss modules/Products/PythonScripts/standard"> <div tal:content="python:pss.dollars_and_cents(5.0)"> $1.00 </div> </span> You could argue against the define at the beginning, but I think of those as being analogous to python import statements: "before I get started, I'm going to give myself convenient access to the stuff I need." You could also argue that we need a non-US-centric currency formatter, and I agree; but I say again that we need it everywhere and not only via some special syntax in ZPT. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's OUR ROCKET PERVERT! (random hero from isometric.spaceninja.com)
Shane Hathaway wrote at 2003-7-23 10:48 -0400:
... Think of prefixes as site-wide, generally useful Python scripts. Quite often some API returns something that's intuitively easy to present, but ZPT's syntax makes it somewhat difficult to present. For example, it should not be necessary to write a Python script or expression every time you want to format the number 5 as "$5.00".
I use TALES since its beginnings and I never needed a monetary format. We will end up with TALES as a huge monster. I am sure, both of us (and many others) will be able to cope with this monster and take advantage of its many features as we did, for example, with the myriads of attributes for "dtml-var" and "dtml-in". However, many others will be overwhelmed by the vast set of options. Be very reluctant to extend TALES. Do not do it do get just syntactic sugar in order to save a few lines of code. I am with you for your "macro argument" proposal as it makes METAL much easier to understand and more explicite. I would like to get some documentation facility to be able to document macros, again to make them clearer and easier to maintain. And I would like some way for a macro to refer to its template in order to build macro libraries (I think, we need this). But the prefix proposal seems to me like syntactic sugaring. I would use it when it were implemented but I do not really need it. Dieter
Dieter Maurer wrote:
Be very reluctant to extend TALES. Do not do it do get just syntactic sugar in order to save a few lines of code.
I agree that we should be wary. Adding a feature to make something simpler simultaneously complicates the whole picture. To offset that negative, the new feature has to be a lot better than the previous alternatives. Well, here's a sample of what we'd get with prefixes in path expressions, all with a very minimal addition to TALES. "call:" eliminates the need for implicitly calling things. Purely explicit calling would eliminate a major class of bugs. "format:" provides access to the same string formatting API that previously required importing a module. In fact, it seems unlikely you'll want to import *any* modules in templates anymore. "zope:" gives you access to a nice Zope-specific API, again without importing a module. "dc:" lets you access simple Dublin Core metadata. Perhaps "here/title" should even be deprecated and replaced with "here/dc:title", since it's more explicit and more likely to generate the expected result, yet no more work. I almost forgot to mention the most compelling reason why we need prefixes: in Zope 3, we won't be able to fall back on implicit acquisition anymore, so we need something to replace it. Here's the (old) proposal that explains it all-- http://dev.zope.org/Zope3/NamespacesInTemplates You see, prefixes are meant to let you work comfortably in an otherwise excruciatingly explicit world. :-) Shane
It is absolutely amazing how slippery this stuff is to pin down. The same ideas keep popping up and then slowly subsiding under the weight of exceptions, prefixes and caveats. I kinda suspect the only way is to deliver a specific take on the whole thing, like Evan did with the current ZPT, and to see how that pans out, instead of teasing the current ZPT to creep after features. That said (he continues blithely), the one bit about the current one that bugs me is the behaviour of callables in path expressions. This is the one I like:: tal:define="value here/func/dict-returned-by-func/key" tal:define="value here/obj/method/returned-dict/key" tal:define="value here/dict/key/obj-stored-under-key/method" That's the one with the downer that func can't get parameters. I'm totally fine with that. For parameters:: tal:define="dict python:here.func('parameter'); value dict/key" -- Jean Jordaan http://www.upfrontsystems.co.za
Shane Hathaway wrote:
Here's the way I'd like to spell it:
<div tal:repeat="user_files here/listFilesByUser"> User: <span tal:replace="user_files/int:0" /> File: <span tal:replace="user_files/int:1" /> </div>
+1
We've come up with a number of generally useful prefixes, BTW. Off the top of my head:
call: -- Call a named method int: -- Look up an item by index format: -- Perform simple formatting operations like "format:money" zope: -- Access a big Zope API
+1
It sure would be nice to have these prefixes, both in Zope 2 and Zope 3.
AFAIK, Jim wants this for Zope3 for some time now. The idea is to implement this with named adapters. here/some_object/zope:name would make TALES look up the 'zope' adapter (something that implements zope.app.interfaces.talesapi.IZopeTalesAPI) and get its name attribute/call its name() method. It would really be a two-liner to implement something like an 'int' or 'call' adapter. Other named adapters like 'dc' that adapts an object to a Dublin Core interface would be nice to have as well. A lot of that is in place already, fortunately. The question remains how to implement this in Zope2 as we don't have adapters there. Philipp
Philipp von Weitershausen wrote:
AFAIK, Jim wants this for Zope3 for some time now. The idea is to implement this with named adapters.
The framework is implemented, as are one or two examples, IIRC...
The question remains how to implement this in Zope2 as we don't have adapters there.
The implementation in Zope 3's TALES engine doesn't rely on Adapters, take a look :-) cheers, Chris
On Wed, 23 Jul 2003 10:00:37 -0400 Shane Hathaway <shane@zope.com> wrote:
We've come up with a number of generally useful prefixes, BTW. Off the top of my head:
call: -- Call a named method int: -- Look up an item by index
Hate this. Looks like a typecast of some kind, int is way to overused for this. If you must, why not index: ? Jim Penny
format: -- Perform simple formatting operations like "format:money" zope: -- Access a big Zope API
It sure would be nice to have these prefixes, both in Zope 2 and Zope 3.
Shane
int: -- Look up an item by index
Hate this. Looks like a typecast of some kind, int is way to overused
Aesthetically, I also find it ugly. The attractiveness of a *path* expression lies in its resemblance to a *path*. But I realise it's like the weird ++elements in Zope3 paths that I hope never to need to deal with but will have to swallow sometime willy nilly, and that no-one could think of anything better in that case :| -- Jean Jordaan http://www.upfrontsystems.co.za
Jean Jordaan wrote:
int: -- Look up an item by index
Hate this. Looks like a typecast of some kind, int is way to overused
Aesthetically, I also find it ugly. The attractiveness of a *path* expression lies in its resemblance to a *path*.
True, but we've obviously reached a point where a simple POSIX like path is not sufficient anymore, because we apply it to a complicated Zope structure. some_function/returned-dict/some_key is really comparing "apples to a whole fruit salad" (quote from ChrisW or SteveA, can't remember). Thus we need to attach some kind of extra meaning to the elements, not only to tell Zope where they come from and how they have been interpreted, but also to make it cleaner for the programmer.
But I realise it's like the weird ++elements in Zope3 paths that I hope never to need to deal with but will have to swallow sometime willy nilly, and that no-one could think of anything better in that case :|
Tough luck :). Well, it's actually the same thing as above. In Zope2, we've mixed content, configuration, code and presentation in one namespace. Since Zope3 inforces their separation, it only makes sense to have them live in different namespaces as well (we have ++etc++, ++skin++, ++vh++ and some more). The decision what token to use for identifying namespaces has long been made. Sorry if you don't like it now... :( Cheers, Phil
Jim Penny wrote:
Hate this. Looks like a typecast of some kind, int is way to overused for this. If you must, why not index: ?
Hmmm. I hadn't thought of that before, but I've certainly wanted to tell the path traverser whether to use attribute, index, or key access on several occasions (using 'items' as a dictionary key bites me regularly). This suggests the following prefixes: 'key:' -- use item access with the prefixed string. 'index:' -- use item access with the prefixed integer. 'attr:' -- use attribute access with the prefixed string. In each case, the path traversal fails if the specified access method fails, rather than trying other access methods. This would allow "options/a_mapping/key:items/index:0" rather than "python:options['a_mapping']['items'][0]". There's an alternative, longer syntax that would be more consistent with the adapter concept from Zope 3. Given that prefixes are meant to be namespaces, 'key', 'index', and 'attr' should be elements of a namespace (perhaps 'by' or 'as' to keep it reasonably short) rather than prefixes themselves. In this case, we would have the path expression "options/a_mapping/by:key/items/by:index/0". Note that this form has the advantage of allowing "a_list/by:index/?i". Cheers, Evan @ 4-am
Evan Simpson wrote:
Hmmm. I hadn't thought of that before, but I've certainly wanted to tell the path traverser whether to use attribute, index, or key access on several occasions (using 'items' as a dictionary key bites me regularly).
I can imagine the pain. Explicit is better than implicit.
This suggests the following prefixes:
'key:' -- use item access with the prefixed string. 'index:' -- use item access with the prefixed integer. 'attr:' -- use attribute access with the prefixed string.
+1
There's an alternative, longer syntax that would be more consistent with the adapter concept from Zope 3. Given that prefixes are meant to be namespaces, 'key', 'index', and 'attr' should be elements of a namespace (perhaps 'by' or 'as' to keep it reasonably short) rather than prefixes themselves. In this case, we would have the path expression "options/a_mapping/by:key/items/by:index/0".
*ugh*. Too long. You'd keep adding thousands of elements to your TALES expression...
Note that this form has the advantage of allowing "a_list/by:index/?i".
Why wouldn't that be possible with "a_list/index:?i"? Phil
Philipp von Weitershausen writes:
Why wouldn't that be possible with "a_list/index:?i"?
I think making it "a_list/index:i" is fine. The adapter for "index:" will get the index as a string and convert that to an integer and return a_list[i]. The index: adapter simply represents a namespace in which all names look like integers. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
(I'm cc'ing zope-dev this time) Evan Simpson wrote:
Jim Penny wrote:
Hate this. Looks like a typecast of some kind, int is way to overused for this. If you must, why not index: ?
Hmmm. I hadn't thought of that before, but I've certainly wanted to tell the path traverser whether to use attribute, index, or key access on several occasions (using 'items' as a dictionary key bites me regularly). This suggests the following prefixes:
'key:' -- use item access with the prefixed string. 'index:' -- use item access with the prefixed integer. 'attr:' -- use attribute access with the prefixed string.
I agree, "index:" is better. I had a mental block that made me think of only "item:", which would be ambiguous. Shane
On Wed, Jul 23, 2003 at 11:07:20AM -0500, Evan Simpson wrote:
... This would allow "options/a_mapping/key:items/index:0" rather than "python:options['a_mapping']['items'][0]".
Why is that an improvement? surely it's not saving 3 characters that makes the new syntax worthwhile...
"options/a_mapping/by:key/items/by:index/0".
do you find this easier to read or write than the python version? I guess I don't understand the goal. Are we trying to make it so that zpt authors don't have to know any python? I really think that's a mistake. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's RED ORIGAMI SNOWMAN! (random hero from isometric.spaceninja.com)
Paul Winkler writes:
I guess I don't understand the goal. Are we trying to make it so that zpt authors don't have to know any python? I really think that's a mistake.
There are those that consider using python: expressions in ZPT should be discouraged, primarily because it's yet another syntax for a web developer to learn. I'm not necessarily one of them, but I am sympathetic with that reasoning. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
On Wed, Jul 23, 2003 at 02:04:51PM -0400, Fred L. Drake, Jr. wrote:
There are those that consider using python: expressions in ZPT should be discouraged, primarily because it's yet another syntax for a web developer to learn.
I'm not necessarily one of them, but I am sympathetic with that reasoning.
I'm definitely not one of them. I am sympathetic with the impulse - don't place too many burdens on the web developer - but I think that in this case it's misguided. I don't mean to be harsh, but I feel very strongly about this: I think it is wrong to think that one can be an effective web developer with zope and never have to write a single python expression. WHen I started using zope, lots of people were trying to build entire applications with nothing but DTML and propertysheets and the like. The result was some really horrid DTML. I am still maintaining some of this gunk, and I'm really looking forward to the day I can finally rewrite our oldest running zope apps. The solution to DTML-from-hell was to refactor the logic into scripts written in - guess what - python. This is now widely regarded as best practice for quick through-the-web scripting and site development in zope. I always thought that one of the key design goals for TAL/TALES was to be very minimal and *force* the developer to offload anything difficult into python. I think ZPT is successful partly because of this feature. My concern is that ZPT will grow so many conveniences that it will become easier to abuse it in the same way that DTML has been widely abused. New zope developers will then be more tempted to avoid python ("i don't have time to learn another language") and with the best intentions will do themselves a serious disservice: a lot of things will still be unnecessarily difficult compared to using python, and a lot of logic will be in templates where it doesn't belong. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's LORD MC-FJUKER! (random hero from isometric.spaceninja.com)
Paul Winkler wrote:
On Wed, Jul 23, 2003 at 02:04:51PM -0400, Fred L. Drake, Jr. wrote:
There are those that consider using python: expressions in ZPT should be discouraged, primarily because it's yet another syntax for a web developer to learn.
I'm not necessarily one of them, but I am sympathetic with that reasoning.
That's not my reasoning either. :-) My feeling is that you should avoid mixing syntaxes in a single document. The more syntaxes you mix, the more perfection you require of developers. Take the following code: <pre tal:content="python: text.replace('\\n', '<br /')" /> This code has at least four errors (one XML, one HTML, one ZPT, one Python--can you spot them?), but it will work anyway without complaint. This is hard to debug because it requires complete understanding and perfect spelling of four languages at once: XML, ZPT, HTML, and Python. I wholeheartedly agree that newcomers should learn Python as well as ZPT, but there should be a clean separation of the two.
My concern is that ZPT will grow so many conveniences that it will become easier to abuse it in the same way that DTML has been widely abused. New zope developers will then be more tempted to avoid python ("i don't have time to learn another language") and with the best intentions will do themselves a serious disservice: a lot of things will still be unnecessarily difficult compared to using python, and a lot of logic will be in templates where it doesn't belong.
I have a slightly different concern. You're concerned that people will use path expressions when they could use Python expressions. I'm concerned that people will use *any* kind of complicated expressions instead of Python code blocks. To me, the choice between path expression and Python expression isn't very meaningful; either way I'm putting logic in a template, and if it's too complicated, it doesn't belong there. The better goal is to move complicated logic out of templates and into Python code blocks, don't you think? I know of two ways to avoid writing complicated expressions in templates: 1. Move complicated expressions into Python code blocks. 2. Provide a simpler equivalent for complicated expressions. Prefixes in the middle of path expressions attacks #2. Shane
On Wed, Jul 23, 2003 at 05:15:48PM -0400, Shane Hathaway wrote:
Paul Winkler wrote:
On Wed, Jul 23, 2003 at 02:04:51PM -0400, Fred L. Drake, Jr. wrote:
There are those that consider using python: expressions in ZPT should be discouraged, primarily because it's yet another syntax for a web developer to learn.
I'm not necessarily one of them, but I am sympathetic with that reasoning.
That's not my reasoning either. :-)
My feeling is that you should avoid mixing syntaxes in a single document. The more syntaxes you mix, the more perfection you require of developers.
Ah. yes, i think there's something to that.
Take the following code:
<pre tal:content="python: text.replace('\\n', '<br /')" />
This code has at least four errors (one XML, one HTML, one ZPT, one Python--can you spot them?),
heheh, good example... took me a while to find 4 :-)
but it will work anyway without complaint. This is hard to debug because it requires complete understanding and perfect spelling of four languages at once: XML, ZPT, HTML, and Python.
yeah, that sucks. Maybe I'm just upset that you want to remove my favorite of the four. :-) Given the context, of course, python is the only one that's a candidate for removal from the template.
I wholeheartedly agree that newcomers should learn Python as well as ZPT, but there should be a clean separation of the two.
I think I'd have to try rewriting some of my complex templates with no python expressions whatsoever before I'd know if I agree with you.
I have a slightly different concern. You're concerned that people will use path expressions when they could use Python expressions. I'm concerned that people will use *any* kind of complicated expressions instead of Python code blocks. To me, the choice between path expression and Python expression isn't very meaningful; either way I'm putting logic in a template, and if it's too complicated, it doesn't belong there. The better goal is to move complicated logic out of templates and into Python code blocks, don't you think?
Yes, I do. But I've found that when I write templates, there is a typical progression: 1. Start with a simple path expression: request/foo 2. Whoops, now I need to do something a bit more involved: python:here.do_something(request.foo, here.something_else, ...) 3. ugh, it's getting too long - move the python expression into foo_script and change the tales expression to: here/foo_script The current proposals aim to reduce the need to go to step 2. Nice goal - it is true much of my ugliest template code has been caused by pushing 2 too far. But I find that going from step 2 to step 3 is so easy that I don't mind refactoring and it's usually very quick. However... it should be noted that step 2 can be completely bypassed. There's nothing preventing me from going from 1 directly to 3. I only use 2 because it's there :-) Thinking more about it, it occurs to me that python expressions in TALES provide a huge hole in the separation of presentation from logic. Consider the psychological factor - python expressions are convenient sometimes. Many of us do not have the willpower to resist. :-) Adding features to TALES doesn't change this, it gives us another brand of rope to hang ourselves with.
I know of two ways to avoid writing complicated expressions in templates:
1. Move complicated expressions into Python code blocks.
2. Provide a simpler equivalent for complicated expressions.
what about: 0. make complicated expressions illegal I'm only half-joking. Why are we arguing for adding more stuff to TALES rather than removing python expressions? Can someone think of an example that *requires* a python expression and can't be done with a path expression and a Script? If so, is it solvable by improving the interaction between templates and Scripts instead of adding features to Templates? I seriously doubt this would meet community approval for zope 2, there's too much existing code that would break. but maybe it should be considered (if it hasn't been already) for zope 3.
Prefixes in the middle of path expressions attacks #2.
hm. i guess i would agree if I thought any of the proposals actually are significantly simpler! Let's stick to your first point - python in ZPT is undesirable because ZPT already makes you deal with 3 languages (assuming the output is html and not just XML). But since we are stuck with 3 languages in one file, why do we want to make one of them more complex than it already is? And since we know that we very often need a fourth language in another file, why not leverage that capability to keep the template super-simple? -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's PORN STAR OMEGA! (random hero from isometric.spaceninja.com)
On Wed, Jul 23, 2003 at 06:15:46PM -0400, Paul Winkler wrote: (snip)
I think I'd have to try rewriting some of my complex templates with no python expressions whatsoever before I'd know if I agree with you. (snip) I only use 2 because it's there :-) Thinking more about it, it occurs to me that python expressions in TALES provide a huge hole in the separation of presentation from logic.
I didn't mean to sound schizo... i'm just thinking out loud! :-) -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's MOSTLY-PENGUIN WEARING A HAT! (random hero from isometric.spaceninja.com)
I only use 2 because it's there :-) Thinking more about it, it occurs to me that python expressions in TALES provide a huge hole in the separation of presentation from logic.
Perhaps it's worthwhile for this thread to have a look at http://www.eby-sarna.com/pipermail/transwarp/2003-July/000606.html http://www.eby-sarna.com/pipermail/transwarp/2003-July/000607.html and following to see what Phillip Eby is cooking up. The templates he proposes have only two or three attributes, keeping logic rigorously out of the template. -- Jean Jordaan http://www.upfrontsystems.co.za
On Thu, Jul 24, 2003 at 11:00:09AM +0200, Jean Jordaan wrote:
Perhaps it's worthwhile for this thread to have a look at http://www.eby-sarna.com/pipermail/transwarp/2003-July/000606.html http://www.eby-sarna.com/pipermail/transwarp/2003-July/000607.html and following to see what Phillip Eby is cooking up.
The templates he proposes have only two or three attributes, keeping logic rigorously out of the template.
Very interesting idea. Here's an excerpt: """ I think that ZPT still embed code in a web page, and that there's a better alternative. If you've seen PSO (pso.sf.net), Twisted's Woven, or even JSP taglibs (though that's a bit of a stretch), you'll have a better idea of what PWT (peak.web.templates) looks like. Here's an example, straight from the test suite: <body> <h1 model="foo" view="text">Title Goes Here</h1> <ul model="bar" view="list"> <li pattern="listItem" view="text"></li> </ul> </body> 'view' attributes identify the object factory used to create the tag, 'model' attributes are a path to the data to be used, and 'pattern' attributes identify parameters that are supplied to the nearest containing 'view', rather like a METAL macro slot (except that views are written in Python, rather than being templates, although I intend to make it possible to use a template as a view, too). Views are looked up in a property namespace so you can configure access to arbitrary view components that your app (or anybody else) supplies.... """ I don't totally grok it (an object factory creates a tag? does he mean the contents of the tag? and since they're factories written in python shouldn't they be called something other than 'views'? like maybe 'factory'??). But, odd terminology aside, it's compellingly simple. I guess that the 'view' and the 'model' only have to agree on an interface ('pattern' names). -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's DEPUTY SHERIFF OF JUSTICE! (random hero from isometric.spaceninja.com)
I only use 2 because it's there :-) Thinking more about it, it occurs to me that python expressions in TALES provide a huge hole in the separation of presentation from logic.
My view is that embedding logic in presentation isn't quite the right thing to avoid. Consider how much "logic" goes into presenting HTML on the client side. Yet browsers can't perform all of the logic, so some presentation logic has to exist on the server side. Instead, two things are important: distinguishing presentation from the model and keeping syntax simple. Python expressions in templates rarely violate the first principle because they are not part of the model. (Contrast this with PHP, where the model exists only in the presentation.) Complex expressions violate the second principle because the syntax becomes unwieldy. Jean Jordaan wrote:
Perhaps it's worthwhile for this thread to have a look at http://www.eby-sarna.com/pipermail/transwarp/2003-July/000606.html http://www.eby-sarna.com/pipermail/transwarp/2003-July/000607.html and following to see what Phillip Eby is cooking up. The templates he proposes have only two or three attributes, keeping logic rigorously out of the template.
I like the idea. It's a novel approach. It may be oversimplifying, though, and the danger of oversimplifying is that some other part acquires extra complexity to compensate. For example, if we were to ban Python expressions outright in ZPT, it would become necessary to compensate by writing at least one Python script per template that used to have expressions. In a product I'm maintaining for a customer, that would be a very big burden. Shane
Paul Winkler wrote:
On Wed, Jul 23, 2003 at 11:07:20AM -0500, Evan Simpson wrote:
... This would allow "options/a_mapping/key:items/index:0" rather than "python:options['a_mapping']['items'][0]".
Why is that an improvement?
Personally, I find it much easier to read... I wonder what non-python'ers would think?
I guess I don't understand the goal. Are we trying to make it so that zpt authors don't have to know any python?
For me, that would be ideal...
I really think that's a mistake.
What leads you to believe that? cheers, Chris
Am Dienstag, 29. Juli 2003 19:22 schrieb Chris Withers:
Paul Winkler wrote:
On Wed, Jul 23, 2003 at 11:07:20AM -0500, Evan Simpson wrote:
... This would allow "options/a_mapping/key:items/index:0" rather than "python:options['a_mapping']['items'][0]".
Why is that an improvement?
Personally, I find it much easier to read...
I wonder what non-python'ers would think?
For casual ZPT users and newbies it is confusing to use two different notations for doing "the same" For this group of users the modification as proposed would be great. -- mit freundlichen Grüssen Robert Rottermann www.redCOR.ch
On Tue, Jul 29, 2003 at 06:22:38PM +0100, Chris Withers wrote:
Paul Winkler wrote:
On Wed, Jul 23, 2003 at 11:07:20AM -0500, Evan Simpson wrote:
... This would allow "options/a_mapping/key:items/index:0" rather than "python:options['a_mapping']['items'][0]".
Why is that an improvement?
Personally, I find it much easier to read...
I find the opposite: Assuming that the reader understands python, s/he has to perform the mental translation anyway in order to understand how this expression uses the objects it refers to. Assuming that the reader does NOT understand any python, it doesn't make much sense. The immediate questions arise: "What's a key?" "What's an index?" "What's the difference between them?" "How do I know when to use one or the other?" And, how do you answer those questions without talking about python data structures?
I wonder what non-python'ers would think?
well, that's a very good and relevant question, but I doubt we will find them on this mailing list :-) I would really like to know.
I guess I don't understand the goal. Are we trying to make it so that zpt authors don't have to know any python?
For me, that would be ideal...
I really think that's a mistake.
What leads you to believe that?
The appeal of TALES path expressions lies in their simplicity. I don't want them to feature-creep into a general purpose programming language. The more complex these expressions get, the more work a zope developer (e.g. someone developing new content types, services, etc.) has to expend on mentally translating between different languages, which is always an opportunity to get something wrong as we've already discussed. We all know that Python has a near-unbeatable record as an easy-to-use, well-designed, and downright fun language. It has a great reputation as a "first language". These new proposals for TALES path expressions do not have any such track record, so I am naturally skeptical that they are going to beat python at one of its strengths: readability and novice-friendliness. Consider what happened with Zope 2 and DTML: the templating language had enough features that novice developers often got themselves into trouble by writing excessively complex templates with embedded logic. The zope 2 tutorial and most other available documents gave the impression that you didn't need to learn python to get things done in Zope. Since the addition of ZPT and Python Scripts, things have improved enormously; but I remember a time when the zope@zope.org list was full of questions like "how do I do my complex task in DTML". It was easy to get your feet wet, and without clear & explicit ways to use python, it was easy to fall off the continental shelf where suddenly nothing worked anymore and nothing made sense. So I am very wary of ZPT becoming "Son of DTML From Hell", and that's what the proposed extensions smell like to me. To frame it as a practical question: how is the template author going to get something non-trivial done? Assuming that TALES python expressions are banned/discouraged/whatever, there are 3 choices: 1) The template author writes some auxiliary python code (whether this is a script or a Product or a Persistent Module or whatever). This is the case most familiar to me - I'm usually doing most of my work alone. In this case the author has to know both ZPT and python - but not both in the same document. 2) Stretch the capabilities of the template language so that no python is necessary anywhere. I think we agree that *currently* this is bad practice, when it's even possible. 3) Get somebody else to write the python code, and just refer to the code objects with TALES path expressions. This is what I think you are suggesting - yes? no? It's hard for me to imagine working strictly in this fashion, because in my limited experience I've never worked that way and I don't know anybody who does. *Do* people actually work this way? If you don't know any python, isn't it tempting to write some icky template code yourself instead of waiting for the code guy to have time to help you? -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's USELESS MEGA BOY! (random hero from isometric.spaceninja.com)
On Tue, 29 Jul 2003 14:27:34 -0400 Paul Winkler <pw_lists@slinkp.com> wrote:
On Tue, Jul 29, 2003 at 06:22:38PM +0100, Chris Withers wrote:
Paul Winkler wrote:
On Wed, Jul 23, 2003 at 11:07:20AM -0500, Evan Simpson wrote:
... This would allow "options/a_mapping/key:items/index:0" rather than "python:options['a_mapping']['items'][0]".
Why is that an improvement?
Personally, I find it much easier to read...
I find the opposite:
Neither is easy to read. Go to your nearest non-programmer unit, spousal, parental, whatever. Watch the My Eyes Glaze Over, (MEGO) phenomenon take immediate effect.
Assuming that the reader does NOT understand any python, it doesn't make much sense. The immediate questions arise: "What's a key?" "What's an index?" "What's the difference between them?" "How do I know when to use one or the other?" And, how do you answer those questions without talking about python data structures?
I agree with Paul here. I hated the int: because it had nothing to do with indexing. I could reluctantly accept index: -- but it will not help the intended audience. Only programmers understand things like indices, keys, etc. What is worse, is that it builds a bunch on un-pythonic syntax, which will get in the way of learning python later. Let ZPT handle the simplest things, and escape to python as needed. Lo, ZPT has not even a proper expression syntax. All that is going on here is creating a syntax for some extremely limited special cases, a really non-standard syntax. And, the syntax depends on having some python programmer create the dictionaries or sequences that are being referenced. That to me, is the fatal flaw. It is hard to argue, on one hand, that a python programmer is available to you whenever you need a sequence created, and on the other hand, that he is no longer there to consult/hand work off to when a simple expression is needed. Jim Penny
[Paul Winkler]
I guess I don't understand the goal. Are we trying to make it so that zpt authors don't have to know any python?
[Chris Withers]
For me, that would be ideal...
[Paul Winkler]
I really think that's a mistake.
Guys, that line of thinking is a distraction. ZPT authors ought to learn Python. The issue is deeper than that. I'll explain below. [Paul Winkler]
Assuming that TALES python expressions are banned/discouraged/whatever, [...]
Python expressions won't be banned. I will never consider them discouraged for all cases, either. There will always be a need for constructs like: <div tal:condition="python: a == b">...</div> <div tal:condition="python: (a and b) or c">...</div> However, the following is quite bad: <tal:x define="ss nocall:modules/Products/PythonScripts/standard"> <a tal:attributes="href python: ss.url_quote(some_url)" /> </tal:x> This is un-Pythonic in numerous ways. - You can't use the import statement. In fact, you can't use any statements at all--only expressions. - The nocall: prefix. - The name 'modules' is present automatically along with many other names that aren't in the Python builtins namespace. - Importing using a path expression. - Binding a variable to a value without an equal sign. - You have to prefix Python expressions with "python:". - You have to be careful not to use double quotes in expressions. (Ampersands and less-than/greater-than signs are tricky too. Watch out for pairs of hyphens!) Zope 2's method of slightly simplifying this is to write a two-line script and find it through implicit acquisition. The overhead of invoking a script is somewhat large, but here's what the template would look like anyway. <a tal:attributes="href python: here.url_quote(some_url)" /> Zope 3 will not have implicit acquisition. In fact, no system but Zope 2 has implicit acquisition. That leaves us with no possible way to write the above statement in non-implicit Python! No matter what you do, you need some help from another kind of expression. Until recently, here was the way to write it in Zope 3. <tal:x define="url_quote nocall:here/++acquire++url_quote"> <a tal:attributes="href python: url_quote(some_url)" /> </tal:x> That alternative is just as complicated and un-Pythonic as importing a module in a template. I can't think of a better way to write this given the limitations of Zope 2 ZPT, without the giant implicit acquisition band-aid. Can you? Zope 3's new alternative looks about like this: <a tal:attributes="href here/format:url_quote" /> To me, that's a vast improvment, and it's only one example. You know what was actually wrong with DTML? The lack of Python Scripts. Without Python Scripts, everyone used DTML as a programming language. Once Python Scripts came around, DTML became a reasonable templating language again. If DTML used TALES expressions, it would be just as clean as ZPT. Shane
Shane Hathaway writes:
- You have to be careful not to use double quotes in expressions. (Ampersands and less-than/greater-than signs are tricky too. Watch out for pairs of hyphens!)
This is FUD. TAL can handle these things quite well; the "problem" is that many web developers don't have a clear understanding of layers of encoding (a seriously unfortunate state of affairs, though understandable given the time pressures of creating/updating a site). Encoding quotes inside an attribute values means that the expression (Python or not) is harder to read, but if it doesn't still work, there's a bug in the implementation. I'll be glad to donate some of my time to fix any such bugs. Othan than this, I agree with you on this topic. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
Fred L. Drake, Jr. wrote:
Shane Hathaway writes:
- You have to be careful not to use double quotes in expressions. (Ampersands and less-than/greater-than signs are tricky too. Watch out for pairs of hyphens!)
This is FUD. TAL can handle these things quite well; the "problem" is that many web developers don't have a clear understanding of layers of encoding (a seriously unfortunate state of affairs, though understandable given the time pressures of creating/updating a site). Encoding quotes inside an attribute values means that the expression (Python or not) is harder to read, but if it doesn't still work, there's a bug in the implementation. I'll be glad to donate some of my time to fix any such bugs.
Othan than this, I agree with you on this topic.
I'm not quite sure what you're saying. The following fails compilation: <span tal:content="python: "abc"" /> Hence you need to be careful not to use double quotes in expressions. I run into this every day. I'm a little wary of expressions like this: <span tal:content="python: 1 > 0" /> ... being converted by buggy XML or HTML software to this (I've seen it happen before): <span tal:content="python: 1 > 0" /> Finally, if you use a pair of hyphens in an expression and later use XML syntax to comment it out while leaving the pair of hyphens, the block is technically not well-formed. http://www.w3.org/TR/REC-xml#sec-comments For example: <!-- <span tal:content="python: 'What should we do--walk or run?'" /> --> This is not something that should bother anyone, but I wanted to support my assertion. ;-) Shane
Shane Hathaway writes:
I'm not quite sure what you're saying. The following fails compilation:
<span tal:content="python: "abc"" />
That's because you've broken the syntax. It should have been: <span tal:content="python: "abc"" /> or, more legibly, <span tal:content="python: 'abc'" /> I think the problem is that it's easy to think of TAL as little bits of different syntaxes, but that's not actually what's happening. The syntaxes are layered on top of each other, and where there are characters meaningful to more than one layer, they have to be encoded so they are interpreted by the proper layer.
Hence you need to be careful not to use double quotes in expressions. I run into this every day.
I'm a little wary of expressions like this:
<span tal:content="python: 1 > 0" />
... being converted by buggy XML or HTML software to this (I've seen it happen before):
<span tal:content="python: 1 > 0" />
That's not buggy; that's what you should have written to start with.
Finally, if you use a pair of hyphens in an expression and later use XML syntax to comment it out while leaving the pair of hyphens, the block is technically not well-formed.
http://www.w3.org/TR/REC-xml#sec-comments
For example:
<!-- <span tal:content="python: 'What should we do--walk or run?'" /> -->
This is not something that should bother anyone, but I wanted to support my assertion. ;-)
That's life. If you change the document, you may have to change context. If you want to make it possible to enclose something in a comment, you have to encode your content differently. For the double hyphen, encode at least one of them like so: <!-- <span tal:content="python: 'What should we do--walk or run?'" /> --> In general, I'd recommend using a syntax-highlighting editor to help detect this one early, or even a "proper" XML editor for those who can tolerate them. I hope this makes sense as I've described it. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
On Tue, 29 Jul 2003 16:43:21 -0400 Shane Hathaway <shane@zope.com> wrote:
[Paul Winkler]
I guess I don't understand the goal. Are we trying to make it so that zpt authors don't have to know any python?
[Chris Withers]
For me, that would be ideal...
[Paul Winkler]
I really think that's a mistake.
Guys, that line of thinking is a distraction. ZPT authors ought to learn Python. The issue is deeper than that. I'll explain below.
[Paul Winkler]
Assuming that TALES python expressions are banned/discouraged/whatever, [...]
Python expressions won't be banned. I will never consider them discouraged for all cases, either. There will always be a need for constructs like:
<div tal:condition="python: a == b">...</div> <div tal:condition="python: (a and b) or c">...</div>
However, the following is quite bad:
<tal:x define="ss nocall:modules/Products/PythonScripts/standard"> <a tal:attributes="href python: ss.url_quote(some_url)" /> </tal:x>
Frankly, would not even have occurred to me - I would probably create a tiny Script (Python) en passant, and called it directly, as: <a tal:attributes="href python: here.url_quote(some_url)" />. I did not realize that this is deprecated in Zope3.
This is un-Pythonic in numerous ways.
snip
<a tal:attributes="href here/format:url_quote" />
To me, that's a vast improvment, and it's only one example.
But, what does all of this have to do with index:, key:, int:, etc.? index: and key: are particularly interesting, in that they use different syntax for something that python conflates syntactically. That is, an integer indexed reference looks exactly like a string indexed reference, both have form structure[key]. Jim Penny
Jim Penny wrote:
Frankly, would not even have occurred to me - I would probably create a tiny Script (Python) en passant, and called it directly, as: <a tal:attributes="href python: here.url_quote(some_url)" />. I did not realize that this is deprecated in Zope3.
Your example relies on implicit acquisition. Your example is not deprecated, it just won't work. :-) Now, if you made a view component, you could get it to work, but that pattern would be very different from Zope 2.
But, what does all of this have to do with index:, key:, int:, etc.?
The issue at hand is whether to use prefixes at all. That's the way I understand it, anyway. Shane
On Tue, 29 Jul 2003 17:51:56 -0400 Shane Hathaway <shane@zope.com> wrote:
Jim Penny wrote:
Frankly, would not even have occurred to me - I would probably create a tiny Script (Python) en passant, and called it directly, as:<a tal:attributes="href python: here.url_quote(some_url)" />. I did not realize that this is deprecated in Zope3.
Ahh, OK. The damned here/context semantic trap again. It is too late to revisit, it is a done deed, it was a really good idea to call the concept context, self, and here, depending on what kind of object you are using, etc. But "here" suggests container more strongly to my mind than container does! So, I try never to use it. Jim Penny
Jim Penny wrote:
Ahh, OK. The damned here/context semantic trap again. It is too late to revisit, it is a done deed, it was a really good idea to call the concept context, self, and here, depending on what kind of object you are using, etc. But "here" suggests container more strongly to my mind than container does! So, I try never to use it.
I believe 'here' is gone in Zope 3. You're only likely to see 'self' if writing code on the filesystem. And we're left with 'context' and 'container', which is pretty clear :-) cheers, Chris
Jim Penny wrote:
But, what does all of this have to do with index:, key:, int:, etc.? index: and key: are particularly interesting, in that they use different syntax for something that python conflates syntactically. That is, an integer indexed reference looks exactly like a string indexed reference, both have form structure[key].
I proposed distinct key: and item: in order to kill some implicit magic before it was born: "x/key:0" is the same as "python:x['0']", while "x/item:0" is the same as "python:x[0]". It seems clear to me that subpath prefixes are going to be part of Zope 3, no matter how opinion on this thread goes. It wasn't hard to implement them for Zope 2, and I find them useful. While I agree that someone who can deal well with "x/item:0" will have no problem with "python:x[0]", I also assert that many such people would join me in prefering "options/lib/data/my.sql/call:/item:0/state" to "options['lib'].data['my.sql']()[0].state" if only because the former allows me to specify access methods *only* for the exceptions to the norm, not for every path step. If that isn't valuable, what about path expressions is? I also offer for general consideration the following: options/foo/item:0 | request/foo/item:0 | default data/stat/fmt:thousands_commas | string:No data. Python expression equivalents, please? Cheers, Evan @ 4-am
On Tue, 29 Jul 2003 17:04:46 -0500 Evan Simpson <evan@4-am.com> wrote:
Jim Penny wrote:
But, what does all of this have to do with index:, key:, int:, etc.? index: and key: are particularly interesting, in that they use different syntax for something that python conflates syntactically. That is, an integer indexed reference looks exactly like a string indexed reference, both have form structure[key].
Well, that is exactly why it will be more confusing to everyone. A python programmer is not expecting them to be different, and a non-programmer has no idea of what keys and indices are, much less how they differ.
I proposed distinct key: and item: in order to kill some implicit magic before it was born:
"x/key:0" is the same as "python:x['0']", while "x/item:0" is the same
as "python:x[0]".
It seems clear to me that subpath prefixes are going to be part of Zope 3, no matter how opinion on this thread goes. It wasn't hard to implement them for Zope 2, and I find them useful. While I agree that
someone who can deal well with "x/item:0" will have no problem with "python:x[0]", I also assert that many such people would join me in prefering "options/lib/data/my.sql/call:/item:0/state" to "options['lib'].data['my.sql']()[0].state" if only because the former allows me to specify access methods *only* for the exceptions to the norm, not for every path step. If that isn't valuable, what about path expressions is?
Eeep, gad no. The python is horrible. The prefix syntax is equally horrible, unfamiliar, and ambiguous! For example, why does call: not have an argument, is it because my.sql is niladic, or is it that '/item:0/state' is the argument? Is "options/lib/data/call:my.sql/item:0/state" equivalent? Are parameters magic? If not, how are they discovered?
I also offer for general consideration the following:
options/foo/item:0 | request/foo/item:0 | default data/stat/fmt:thousands_commas | string:No data.
Python expression equivalents, please?
Yes, alternative is very nice. Yes, it can be done with python:path(), or by refactoring the expression to an script. Yes, the alternatives are harder to read, or more work. Nu? The syntax has kind of odd denotation, on top of everything else. The item:0 applies the integer indexing operator to the options['foo'] which must be a sequence type with parameter 0? (I thought that was index: ) The fmt:thousands_commas construct applies the thousands_commas operator with parameter data['stat']? Doesn't it strike you as odd that sometimes the prefix denotes parameterization, and sometimes it denotes application?
Cheers,
Evan @ 4-am
Jim Penny wrote:
Well, that is exactly why it will be more confusing to everyone. A python programmer is not expecting them to be different, and a non-programmer has no idea of what keys and indices are, much less how they differ.
The explanation isn't that hard, at least for a user with a basic knowledge of data structures -- you usually use key: with a dictionary, and item: with a sequence. The exception is when you have an integer key in a dictionary.
Eeep, gad no. The python is horrible. The prefix syntax is equally horrible, unfamiliar, and ambiguous! For example, why does call: not have an argument
Because I'm not passing an argument to the SQL statement. In my implementation, the syntax is "call:arg1,arg2,...", where each argument is required to be a variable name. Every prefixed path element operates upon the current traversal object, using the argument (if any) to the prefix. Here's a list that demonstrates: x/key:foo --> x['foo'] x/item:0 --> x[0] x/attr:foo --> x.foo x/call:foo --> x(foo) x/var:foo --> getattr(x, foo) or x[foo] (path traversal semantics) x/fmt:%.2f --> '%.2f' % x x/fmt:thousands_commas --> thousands_commas(x)
Yes, alternative is very nice. Yes, it can be done with python:path(), or by refactoring the expression to an script. Yes, the alternatives are harder to read, or more work. Nu?
I can't think of a way to implement my first example using python:path(), though you could certainly do it with a Script. The second example can be awkwardly rewritten by defining "exists:data/stat" and using it in a short-circuiting boolean expression such as "have_stat and thousands_commas(data.stat) or 'No data.'". My point is that these prefixes allow a degree of precision, when necessary, that is not possible in current TALES without totally transforming the expression.
Doesn't it strike you as odd that sometimes the prefix denotes parameterization, and sometimes it denotes application?
I hope that the list above makes the consistency clearer. Cheers, Evan @ 4-am
On Wed, Jul 30, 2003 at 12:13:41PM -0500, Evan Simpson wrote:
The explanation isn't that hard, at least for a user with a basic knowledge of data structures --
they have a basic knowledge of data structures but they can't be taught to write a python script in about the same amount of time?
you usually use key: with a dictionary, and item: with a sequence. The exception is when you have an integer key in a dictionary.
That exception does smell a bit funny... having to say here/some_dict/item:0 just feels odd. But I can't remember ever using integers as dictionary keys so it's probably not worth fussing over. :-)
I hope that the list above makes the consistency clearer.
actually it does help a bit, thanks. hmm. It's not horrible :-) I'm just still on the fence about whether we really need it. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's BUTCHER BROMO-BOTTLE CAP! (random hero from isometric.spaceninja.com)
On Wed, 30 Jul 2003 12:13:41 -0500 Evan Simpson <evan@4-am.com> wrote:
Jim Penny wrote:
Well, that is exactly why it will be more confusing to everyone. A python programmer is not expecting them to be different, and a non-programmer has no idea of what keys and indices are, much less how they differ.
The explanation isn't that hard, at least for a user with a basic knowledge of data structures -- you usually use key: with a dictionary, and item: with a sequence. The exception is when you have an integer key in a dictionary.
It is in fact not only hard to teach, it is impossible to use. Look, the ZPT programmer has no way of discovering whether the python programmer has returned a dictionary, a sequence, a Set, or anything else, much less what the key type is. Introspection is not available to a ZPT programmer. So, you are back to asking the python programmer, who just as well do the work. And why would I expect a ZPT person to have a basic knowledge of data structures?
Eeep, gad no. The python is horrible. The prefix syntax is equally horrible, unfamiliar, and ambiguous! For example, why does call: not have an argument
Because I'm not passing an argument to the SQL statement. In my implementation, the syntax is "call:arg1,arg2,...", where each argument is required to be a variable name. Every prefixed path element operates upon the current traversal object, using the argument (if any) to the prefix. Here's a list that demonstrates:
x/key:foo --> x['foo'] x/item:0 --> x[0] x/attr:foo --> x.foo x/call:foo --> x(foo) x/var:foo --> getattr(x, foo) or x[foo] (path traversal semantics) x/fmt:%.2f --> '%.2f' % x x/fmt:thousands_commas --> thousands_commas(x)
Doesn't it strike you as odd that sometimes the prefix denotes parameterization, and sometimes it denotes application?
I hope that the list above makes the consistency clearer.
No, it actually makes it clearer, and worse. It is an interesting notation, kind of, but hugely irregular, and that you and Chris are talking about two quite different semantics on top of a similar syntax does not help things in the least. One by one: key: and item: need to be combined, as they cannot be practically used by the ZPT programmer as separate entities, due to lack of introspection. var: is semantically clear, but I suspect will confuse the hell out of non-programmers. Frankly, and I freely admit that I have not a clue to the implementational details, I would prefer that key:, item:, and var: all be a single entity, say index: x/index:'foo' --> x['foo'] x/index:span_of_int ->x[span_of_int] x/index:foo --> x[foo] call: well, you have said that arguments are allowed, and must be only variable names. What is the reason for this? I assume that only positional parameters are permitted. With named parameters, this is the part I have fewest reservations about. Is there any reason to avoid parentheses however? Does using call: explicitly erase all magic name bindings (I hope so)? Why not x/call:(parameter_list)? There are several reasons to consider this. The primary one is that niladic calls are explicitly marked. Another reason, again with niladic calls is that x/call:()/foo makes is more clear that the foo attribute of x() is being requested, rather than that /foo is an argument to x. The final one is that it would probably permit much more general parameter lists, possibly including constants and/or named parameters. attr: looks clean enough. Combinations of attr: and call: made me think for a while, but, I don't see any obvious problems. fmt: is most irregular. First, it reverses the pattern of all the others and makes the stuff to the left the parameter. This may be OK for your intended audience. It may also confuse them totally. Why x/fmt:%.2f and not x/fmt:'%.2f'? As it stands, it takes either expression fragments starting with % or function names. Can I define my own functions, if so, how/where? Finally, can we come up with a better term than prefix. In conventional terminology, most of these are infix operations, except call, which may be a purely postfix. Jim Penny
Cheers,
Evan @ 4-am
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Jim Penny wrote:
And why would I expect a ZPT person to have a basic knowledge of data structures?
In my view, this whole idea is primarily aimed at programmers. I fully expect that non-programmer ZPT people will be able to ignore this stuff, apart from being handed a small set of idioms by the programmer. Paths that can make use of these features are going to be constructed by programmers, and used as black boxes by ZPT people. The driving rationale behind most of the prefixes that I implemented is to provide explicit spellings for things that have bitten myself and other programmers in practice. 'key', 'item', and 'attr' let us specify access methods when traversal magic fails (eg. method names clashing with keys, no way to access sequence items), and 'call' lets us traverse through simple data-access methods. 'var' is just a less-cryptic version of '?'-prefixed path elements. Several of your objections/suggestions involve the distinction between a string and a name, as in:
x/index:'foo' --> x['foo'] x/index:span_of_int ->x[span_of_int] x/index:foo --> x[foo]
I'd rather not introduce additional punctuation (quotes or parens) if I can help it -- TAL and TALES both have a tradition of minimalist syntax, and it keeps parsing simple. Also, as soon as you add delimiters, you add quoting issues, and TALES has enough of those already.
call: well, you have said that arguments are allowed, and must be only variable names. What is the reason for this?
To keep things simple. There's a clearly visible slippery slope here, and I hope to stay off of it, since it leads to full-on Python in the middle of a path, which would be a nightmare. Names-only takes care of the most common case, while allowing for dead-simple parsing (arg.split(',') then validate each name).
Does using call: explicitly erase all magic name bindings (I hope so)?
I don't know what you mean, here.
fmt: is most irregular. First, it reverses the pattern of all the others and makes the stuff to the left the parameter. This may be OK for your intended audience. It may also confuse them totally. Why x/fmt:%.2f and not x/fmt:'%.2f'? As it stands, it takes either expression fragments starting with % or function names. Can I define my own functions, if so, how/where?
'fmt' is a quick-and-dirty implementation, and most likely to change. It was almost certainly a mistake to conflate the standard formatting functions with Python string formatting. I don't agree that it reverses the pattern, though -- to me, it's "apply *this* formatting operation to the current object", much like 'key' is "fetch *this* key from the current object". One of my to-do's on this idea is syntax allowing prefix strings to be associated with an implementation within a template, possibly overriding the default associations. In particular, this would allow you to make a prefix for a collection of your own functions.
Finally, can we come up with a better term than prefix. In conventional terminology, most of these are infix operations, except call, which may be a purely postfix.
'prefix' refers to the syntax, not the operations. In my source code comments, I refer to "prefixed path elements". A better name would be welcome :-) Cheers, Evan @ 4-am
On Wed, 30 Jul 2003 15:59:47 -0500 Evan Simpson <evan@4-am.com> wrote:
Several of your objections/suggestions involve the distinction between a string and a name, as in:
x/index:'foo' --> x['foo'] x/index:span_of_int ->x[span_of_int] x/index:foo --> x[foo]
I'd rather not introduce additional punctuation (quotes or parens)
But you've already crossed the Rubicon, :, ',', and % have been introduced as punctuation (yes, not matched, which does make a difference)! I am not opposed to this idea, per se, I am worried about the fact that it is so slippery slopish, and that it is so non-standard notationally. As a add-on product, I would say, go for it! As core functionality, it worries me. Further, this is an engineering trade-off. You are trading parsing simplicity by requiring extra programmer awareness - things which a python programmer is often not consciously aware of. I am trying to strongly point this out, so that you are prepared for the inevitable confusion later.
if I can help it -- TAL and TALES both have a tradition of minimalist syntax, and it keeps parsing simple. Also, as soon as you add delimiters, you add quoting issues, and TALES has enough of those already.
call: well, you have said that arguments are allowed, and must be only variable names. What is the reason for this?
To keep things simple. There's a clearly visible slippery slope here,
Yes, but named parameters can be very nice, especially working with databases, they let you match between form names, which are often very specific and database column names which are often more generic. And permitting constants keeps the programmer from an artificial requirement to define bind a constant to a name just to use it in a conditional section. I do understand the parsing issues, and can accept them, although I really would prefer named parameters be available, even if I have to give up constants. I strongly would urge you to use parentheses to denote functional application. Yes, I know there are alternative traditions, but they are much less common in practice. And the strongest one, RPN, was widely hated by 'the masses'.
Does using call: explicitly erase all magic name bindings (I hope so)?
I don't know what you mean, here.
Well, grabbing missing parameters from request, and possibly (zope2) other places.
fmt: is most irregular. First, it reverses the pattern of all the others and makes the stuff to the left the parameter. This may be OK for your intended audience. It may also confuse them totally. Why x/fmt:%.2f and not x/fmt:'%.2f'? As it stands, it takes either expression fragments starting with % or function names. Can I define my own functions, if so, how/where?
'fmt' is a quick-and-dirty implementation, and most likely to change. It was almost certainly a mistake to conflate the standard formatting functions with Python string formatting. I don't agree that it reverses the pattern, though -- to me, it's "apply *this* formatting operation to the current object", much like 'key' is "fetch *this* key from the current object".
well, even if you persist in the mistaken ;-) notion that it is written key: x/key:y --> x[y] x/call:y --> x(y) x/fmt:y --> y(x) 'one of these things is not like the others...'
Finally, can we come up with a better term than prefix. In conventional terminology, most of these are infix operations, except call, which may be a purely postfix.
'prefix' refers to the syntax, not the operations. In my source code comments, I refer to "prefixed path elements". A better name would be welcome :-)
Hmm, maybe 'decorated path'. I am worried that prefix, postfix, and infix already have meaning, and this is more an infix language than a prefix language. But, I lost on 'snake thingy', so I will lose here to :-( Jim Penny
If DTML used TALES expressions, it would be just as clean as ZPT.
With the one caveat that ZPTs are valid XHTML, while DTML methods needn't balance tags and needn't mark empty tags as such (i.e. "<dtml-var x>", instead of "<dtml-var x />"). DTML tags can straddle HTML tags in completely non-XML ways: "<dtml-in items></td></dtml-in>"; limiting the tools that may work with DTML.. The "MTOWTDI" pseudo-entity &dtml-dict.key; alternate syntax might also count against cleanliness. That said, I agree that using TALES would be a big win. We try to use it wherever we can! (Not only in ZPTs :) j
On Tue, Jul 29, 2003 at 04:43:21PM -0400, Shane Hathaway wrote:
Python expressions won't be banned. I will never consider them discouraged for all cases, either. There will always be a need for constructs like:
<div tal:condition="python: a == b">...</div> <div tal:condition="python: (a and b) or c">...</div>
ok.
However, the following is quite bad:
And quite common :-) Browse through some of the CMF skins...
<tal:x define="ss nocall:modules/Products/PythonScripts/standard"> <a tal:attributes="href python: ss.url_quote(some_url)" /> </tal:x>
This is un-Pythonic in numerous ways.
- You can't use the import statement. In fact, you can't use any statements at all--only expressions.
- The nocall: prefix.
- The name 'modules' is present automatically along with many other names that aren't in the Python builtins namespace.
- Importing using a path expression.
agreed on all 4. although, "import" is the only time I miss statements.
- Binding a variable to a value without an equal sign.
That took some getting used to. I don't know why this was chosen, but it seems a bit late to change it now.
- You have to prefix Python expressions with "python:".
That's a feature! If we didn't have that, how would you know the difference between tal:replace="a/b" and tal:replace="python:a/b"
Zope 2's method of slightly simplifying this is to write a two-line script and find it through implicit acquisition. The overhead of invoking a script is somewhat large, but here's what the template would look like anyway.
<a tal:attributes="href python: here.url_quote(some_url)" />
yes, this is about the best you can do currently. In fact, I quite like it. :)
Zope 3 will not have implicit acquisition. In fact, no system but Zope 2 has implicit acquisition. That leaves us with no possible way to write the above statement in non-implicit Python! No matter what you do, you need some help from another kind of expression. Until recently, here was the way to write it in Zope 3.
<tal:x define="url_quote nocall:here/++acquire++url_quote"> <a tal:attributes="href python: url_quote(some_url)" /> </tal:x>
That alternative is just as complicated and un-Pythonic as importing a module in a template. I can't think of a better way to write this given the limitations of Zope 2 ZPT, without the giant implicit acquisition band-aid. Can you?
Zope 3's new alternative looks about like this:
<a tal:attributes="href here/format:url_quote" />
Where do you put the argument? I don't see some_url.
To me, that's a vast improvment, and it's only one example.
It also raises some new questions that are about on par with what would be needed to understand the zope 2 version: What kind of thingie is "format:"? Where can I find it if I want to learn what else it can do? What do I do if I want format:some_custom_format? How could I replace or augment the format thingie and not break any template that uses it? Not that it's bad to raise these questions ... I just want to point out that the answers are far from self-evident.
You know what was actually wrong with DTML? The lack of Python Scripts. Without Python Scripts, everyone used DTML as a programming language. Once Python Scripts came around, DTML became a reasonable templating language again. If DTML used TALES expressions, it would be just as clean as ZPT.
I think I just said this in another post :) -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's MUZZY ANTIDISESTABLISHMENTARIANISTIC FJUKER! (random hero from isometric.spaceninja.com)
Paul Winkler wrote:
On Tue, Jul 29, 2003 at 04:43:21PM -0400, Shane Hathaway wrote:
<a tal:attributes="href here/format:url_quote" />
Where do you put the argument? I don't see some_url.
Oops, I meant this: <a tal:attributes="href some_url/format:url_quote" />
To me, that's a vast improvment, and it's only one example.
It also raises some new questions that are about on par with what would be needed to understand the zope 2 version: What kind of thingie is "format:"? Where can I find it if I want to learn what else it can do? What do I do if I want format:some_custom_format? How could I replace or augment the format thingie and not break any template that uses it?
It is intended that "format:" refers to a Python module. You should not extend that module, unless you're developing Zope itself. You'd find documentation on it in the Zope Book. If you need more functionality, you can configure your own prefixes.
You know what was actually wrong with DTML? The lack of Python Scripts. Without Python Scripts, everyone used DTML as a programming language. Once Python Scripts came around, DTML became a reasonable templating language again. If DTML used TALES expressions, it would be just as clean as ZPT.
I think I just said this in another post :)
Maybe you didn't draw the same conclusion, then. ;-) My conclusion: since the main problem with DTML had little to do with DTML syntax, nothing indicates that ZPT growing pains are going to turn ZPT into a monster. As long as we retain Python Scripts and evolve ZPT slowly, ZPT is in no danger of becoming a problem like DTML did. Shane
Shane Hathaway wrote:
Guys, that line of thinking is a distraction. ZPT authors ought to learn Python.
I dunno about that, I would really like to see simple ZPT require no understanding of python...
language again. If DTML used TALES expressions, it would be just as clean as ZPT.
I actually agree with that, but due to the likelyhood of that happening being so small, and the fact that backwards compatability will mean that the throat-slittingly bad stuff that happened as a result of DTML being used to do logic, and the bulk of really evil example stuff out there, I stick with my view that 'DTML sux'... Chris
Just to throw my 2c into the fray. ZPT is an HTML/XML template language. But what does that mean, really? IMHO. Template languages are data structure navigation languages, or model navigating languages (EEEK, templates having direct access to the model!). And the should avoid being turing-complete (or make it very inconvenient to use turing-complete functionality) I agree in principle with Paul that we should try to reduce the number of concepts (the difference between attribute, key and index access, parameter-less method calling, etc) that we need to expose to template authors (and I find the idea of removing "python:" from TALES slightly tempting). But right now the choice between adding or not the proposed TALES extensions is a choice between having to explain what all those python concepts mean before or after the poor template guy got confused why certain things don't work as expected: * Why must I use a tal:define="something here/getSomeObject" and later a tal:content="something/someAttribute" instead of just tal:content="here/getSomeObject/someAttribute". * Why does tal:content="request/form/items" don't get me the "items" object that I'm expecting * etc.. In order to get to the ideal world Paul wants (and that I want too), maybe we need to restrict the things that TALES can navigate. That would mean we'd need to chose between TALES path navigating dictionary keys or attribute access, but not both. Also, paths would not be able to call anything in the last segment. On the other hand, we'd need to give python scripters the necessary tools, ex. before ZPT, I used to find it VERY anoying that I had to use the mapping attribute in DTML tags just because I couldn't create MyBrain objects thru python. PythonScripts should be able to generate the same kind of objects that ZCatalog and ZSQL queries generate. But in the end, it might be just too much trouble, and we're better off teaching some python to the template guys. At least it's python, and not Perl, PHP or vbscript. Cheers, Leo -- Ideas don't stay in some minds very long because they don't like solitary confinement.
On Tue, Jul 29, 2003 at 07:23:36PM -0300, Leonardo Rochael Almeida wrote:
But right now the choice between adding or not the proposed TALES extensions is a choice between having to explain what all those python concepts mean before or after the poor template guy got confused why certain things don't work as expected:
* Why must I use a tal:define="something here/getSomeObject" and later a tal:content="something/someAttribute" instead of just tal:content="here/getSomeObject/someAttribute".
you don't :) it's a convenience (less stuff to type if you access the object a lot) and/or an optimization (getSomeObject might be expensive).
* Why does tal:content="request/form/items" don't get me the "items" object that I'm expecting
you lost me there.
In order to get to the ideal world Paul wants (and that I want too), maybe we need to restrict the things that TALES can navigate. That would mean we'd need to chose between TALES path navigating dictionary keys or attribute access, but not both.
Hm. Doesn't really matter - ObjectManager makes them equivalent anyway (except that some keys cannot be spelled as attributes, e.g. foo['bar.html']).
Also, paths would not be able to call anything in the last segment.
eh? so tal:content="here/some_method" would no longer work? I don't really understand your proposal I'm afraid.
On the other hand, we'd need to give python scripters the necessary tools, ex. before ZPT, I used to find it VERY anoying that I had to use the mapping attribute in DTML tags just because I couldn't create MyBrain objects thru python. PythonScripts should be able to generate the same kind of objects that ZCatalog and ZSQL queries generate.
Not sure what you mean. You want to wrap Brains around something other than ZSQL results? -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's TWITTY-PHYSICIAN! (random hero from isometric.spaceninja.com)
Paul Winkler wrote:
you don't :) it's a convenience (less stuff to type if you access the object a lot) and/or an optimization (getSomeObject might be expensive).
I believe that his example referred to the case where the intermediate object must be called before path traversal can continue. Since the result of a path expression is called, if possible, the two-step define gets the job done. With prefixes, the simpler "here/getSomeObject/call:/someAttribute" gets the job done.
* Why does tal:content="request/form/items" don't get me the "items" object that I'm expecting
you lost me there.
"request/form" is a mapping, and traversal tries attribute access first, so you get "request.form.items()" rather than "request.form['items']".
Hm. Doesn't really matter - ObjectManager makes them equivalent anyway (except that some keys cannot be spelled as attributes, e.g. foo['bar.html']).
Not quite. Attribute access invokes acquisition, while item access never does, so getattr(foo, 'bar.html') may succeed where foo['bar.html'] fails. Cheers, Evan @ 4-am
On Wed, Jul 30, 2003 at 12:19:35PM -0500, Evan Simpson wrote:
Paul Winkler wrote:
you don't :) it's a convenience (less stuff to type if you access the object a lot) and/or an optimization (getSomeObject might be expensive).
I believe that his example referred to the case where the intermediate object must be called before path traversal can continue.
ah, i see. hm, well if getSomeObject is a Python Script, it's called anyway and it can only deal with someAttribute in its traverse_subpath anyway.
Hm. Doesn't really matter - ObjectManager makes them equivalent anyway (except that some keys cannot be spelled as attributes, e.g. foo['bar.html']).
Not quite. Attribute access invokes acquisition, while item access never does, so getattr(foo, 'bar.html') may succeed where foo['bar.html'] fails.
Ugh. I don't know how I've been using zope 2 this long without noticing that item access doesn't acquire. But i just checked and by golly, you're right. I have to say, that's pretty horrible. :-) Is that documented anywhere? I've never seen it if so. And getattr(foo, "some.string.that's.not.a.valid.python.varname") is just aesthetically bad. :-\ yay zope 2... "principle of most surprise" wins again :-( -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's OVERLY PADDLE SADIST! (random hero from isometric.spaceninja.com)
Evan Simpson wrote:
With prefixes, the simpler "here/getSomeObject/call:/someAttribute" gets the job done.
FWIW, I'd write this as "here/call:getSomeObject/someAttribute". I suppose it's possible to support both. One interesting difference is that my syntax says both "get an attribute" and "call it", while yours says only "call it". Mine is a method call, while yours is a function call. Shane
On Wed, Jul 30, 2003 at 02:06:13PM -0400, Shane Hathaway wrote:
Evan Simpson wrote:
With prefixes, the simpler "here/getSomeObject/call:/someAttribute" gets the job done.
FWIW, I'd write this as "here/call:getSomeObject/someAttribute". I suppose it's possible to support both.
really? How? If you support evan's version, then yours means "call whatever 'here' refers to, and pass getSomeObject as an argument".
One interesting difference is that my syntax says both "get an attribute" and "call it", while yours says only "call it". Mine is a method call, while yours is a function call.
How would you pass arguments in your version? I'd say that passing arguments accounts for a very large percentage of my need to use TALES python expressions. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's UN-LIBIDO OMEGA! (random hero from isometric.spaceninja.com)
Paul Winkler wrote:
On Wed, Jul 30, 2003 at 02:06:13PM -0400, Shane Hathaway wrote:
Evan Simpson wrote:
With prefixes, the simpler "here/getSomeObject/call:/someAttribute" gets the job done.
FWIW, I'd write this as "here/call:getSomeObject/someAttribute". I suppose it's possible to support both.
really? How? If you support evan's version, then yours means "call whatever 'here' refers to, and pass getSomeObject as an argument".
No. I can see how you interpreted it that way, though. "call:" is intended to be a method call, and Evan has provided a way to make it a function call also. In either case, you never pass any arguments. I see the expression "x/call:y" as "call the method named 'y' of 'x'". If no 'y' is provided, as in "x/call:", it means "call 'x'".
One interesting difference is that my syntax says both "get an attribute" and "call it", while yours says only "call it". Mine is a method call, while yours is a function call.
How would you pass arguments in your version? I'd say that passing arguments accounts for a very large percentage of my need to use TALES python expressions.
If you need to pass arguments, use a Python expression. Python expressions are not on trial. If you need to pass exactly one argument, you can use a prefix that implies that. "format:", as I've been using it, is one such prefix. Shane
On Wed, Jul 30, 2003 at 02:29:45PM -0400, Shane Hathaway wrote:
How would you pass arguments in your version? I'd say that passing arguments accounts for a very large percentage of my need to use TALES python expressions.
If you need to pass arguments, use a Python expression. Python expressions are not on trial.
You said in another post: """ My feeling is that you should avoid mixing syntaxes in a single document. """ So I'm getting mixed messages from you. :-) I was bringing up a common case that results in mixing syntaxes, and which won't be avoidable unless the new call: prefix allows arguments. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's CLOWN OF THE MOUNTAINS! (random hero from isometric.spaceninja.com)
Paul Winkler wrote:
On Wed, Jul 30, 2003 at 02:29:45PM -0400, Shane Hathaway wrote:
How would you pass arguments in your version? I'd say that passing arguments accounts for a very large percentage of my need to use TALES python expressions.
If you need to pass arguments, use a Python expression. Python expressions are not on trial.
You said in another post: """ My feeling is that you should avoid mixing syntaxes in a single document. """
So I'm getting mixed messages from you. :-)
They are consistent because neither is absolute. I'm tired of this. Do you have a better alternative to subpath prefixes? The constraints are tight: - You have to make calling explicit. It's important for Zope 3. - You don't get the implicit acquisition crutch anymore. It's important for Zope 3. - You have to provide an easy way to access APIs. It's important for Zope 3. - You have to provide a way to explicitly acquire. It's important for Zope 3! - You can't use Python statements in templates. - Everyone is going to argue over your solution for months. I've tried very hard to invent a way to solve the problems with path expressions without changing TALES. I can't. So I gave myself the flexibility of using just one character that was reserved anyway in path expressions, and the solution fell out. If you want to look for a solution, consider using *only* Python expressions--no path expressions. You'll get a lot of mileage that way, but at the expense of syntax clashes. Who knows, you might find a pretty good solution. Shane
On Wed, Jul 30, 2003 at 04:49:19PM -0400, Shane Hathaway wrote:
I'm tired of this.
Yes indeed :-)
Do you have a better alternative to subpath prefixes? The constraints are tight: (snip)
- You have to provide an easy way to access APIs. It's important for Zope 3.
are you talking about things like z3 services? and/or zope 2 API stuff like foo.objectItems?
- You have to provide a way to explicitly acquire. It's important for Zope 3!
- You can't use Python statements in templates.
right, expressions only...
- Everyone is going to argue over your solution for months.
really???? :-)
I've tried very hard to invent a way to solve the problems with path expressions without changing TALES. I can't. So I gave myself the flexibility of using just one character that was reserved anyway in path expressions, and the solution fell out.
If you want to look for a solution, consider using *only* Python expressions--no path expressions. You'll get a lot of mileage that way, but at the expense of syntax clashes. Who knows, you might find a pretty good solution.
I think this is what I'm going to investigate. Who knows, I might find only bad solutions :-) -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's THE SCIENTIFIC KING LEAR ! (random hero from isometric.spaceninja.com)
On Wed, Jul 30, 2003 at 06:42:39PM -0400, Paul Winkler wrote:
On Wed, Jul 30, 2003 at 04:49:19PM -0400, Shane Hathaway wrote:
Do you have a better alternative to subpath prefixes? The constraints are tight: (snip) If you want to look for a solution, consider using *only* Python expressions--no path expressions. You'll get a lot of mileage that way, but at the expense of syntax clashes. Who knows, you might find a pretty good solution.
This stuff is hard :-\ Attached is what I've been able to come up with. (ducking) -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's THE FISTY FIST ! (random hero from isometric.spaceninja.com)
blargh, sorry about the .htm extension and resulting MIME confusion... i forgot to rename it when i was done playing with it, even though it was only really an html file for the first 5 minutes. -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote:
On Wed, Jul 30, 2003 at 04:49:19PM -0400, Shane Hathaway wrote:
If you want to look for a solution, consider using *only* Python expressions--no path expressions. You'll get a lot of mileage that way, but at the expense of syntax clashes. Who knows, you might find a pretty good solution.
This stuff is hard :-\ Attached is what I've been able to come up with. (ducking)
I must say that using only Python expressions is crippling in a couple of ways. First, it's not true Python if you're only allowed to write expressions. Many language features require statements. Second, we established earlier that Python expressions in templates should have a "python:" prefix, but if every expression uses it, it would be repetitious enough to be annoying. Python's syntax is good, but there are certain uses it doesn't cover well. As another example of something Python syntax doesn't quite fit, I've been pondering lately how to translate the ever-useful 'find' shell command into Python function calls. The Python version always seems to come out a lot more complicated. find . -name '.*' -a -type d -prune -o -name '*.py' -print Shane
Shane Hathaway wrote:
FWIW, I'd write this as "here/call:getSomeObject/someAttribute". I suppose it's possible to support both. One interesting difference is that my syntax says both "get an attribute" and "call it", while yours says only "call it". Mine is a method call, while yours is a function call.
Mine also allows simple argument lists, and supports stuff like "here/key:getSomeObject/call:/someAttribute". On the other hand, it has already confounded someone's intuition :-) Cheers, Evan @ 4-am
Evan Simpson wrote:
'key:' -- use item access with the prefixed string. 'index:' -- use item access with the prefixed integer. 'attr:' -- use attribute access with the prefixed string.
In each case, the path traversal fails if the specified access method fails, rather than trying other access methods. This would allow "options/a_mapping/key:items/index:0" rather than "python:options['a_mapping']['items'][0]".
What an extraordinarily good idea! Why has none of us thought of this before? Like it :-) Chris
OK, I've checked in a sample implementation on "evan-pathprefix-branch". It allows for registering prefixes with: from Products.PageTemplates.PathPrefixes import registerSubPathPrefix registerSubPathPrefix('call', call_compiler, call_handler) It includes an implementation of 'var:', 'call:', 'key:', 'item:', 'attr:', and 'fmt:' with which the snippet: <div tal:define="foo string:*foo*; seq python:('arg', 3.4); map python:{'*foo*': 'yes', 'keys': 'skeleton'}"> <div tal:content="seq/item:0"></div> <div tal:content="seq/item:1/fmt:%.2f"></div> <div tal:content="template/attr:title"></div> <div tal:content="here/key:test3/title"></div> <div tal:content="structure foo/fmt:structured_text"></div> <div tal:content="map/key:keys"></div> <div tal:content="map/var:foo"></div> </div> ...produces: <div> <div>arg</div> <div>3.40</div> <div>My Title</div> <div>My Title</div> <div><p><em>foo</em></p> </div> <div>skeleton</div> <div>yes</div> </div> You can try it out with the following commands in your $ZOPE/lib/python/Products/PageTemplates/ directory: cvs -q up -r evan-pathprefix-branch PathPrefixes.py cvs diff -r evan-pathprefix-branch-0 -r evan-pathprefix-branch \ -u Expressions.py | patch Cheers, Evan @ 4-am
On Wed, 30 Jul 2003 06:16 am, Evan Simpson wrote:
OK, I've checked in a sample implementation on "evan-pathprefix-branch". It allows for registering prefixes with:
This seems very nice. I'm not likely to actually have a chance to play with it any time soon though, so I can't really comment on how it works in practise... Richard
Evan Simpson wrote:
OK, I've checked in a sample implementation on "evan-pathprefix-branch". It allows for registering prefixes with:
from Products.PageTemplates.PathPrefixes import registerSubPathPrefix registerSubPathPrefix('call', call_compiler, call_handler)
How would this interact with the Adapters stuff implements in Zope 3's TALES? I'm pretty sure the implementation there could be used to make this happen, if it was backported to Zope 2's TALES... cheers, Chris
Chris Withers wrote:
How would this interact with the Adapters stuff implements in Zope 3's TALES?
It wouldn't -- this is a Zope 2 implementation. OK, I know what you mean, but I don't know enough about the Zope 3 implementation to make an informed response. Wouldn't Zope 2's lack of the whole component framework make this really hard? Cheers, Evan @ 4-am
Evan Simpson wrote:
It wouldn't -- this is a Zope 2 implementation. OK, I know what you mean, but I don't know enough about the Zope 3 implementation to make an informed response. Wouldn't Zope 2's lack of the whole component framework make this really hard?
Don't think so, the stuff we implemented in the TALES package was agnostic of component architecture... Chris
I have been watching this thread silently for what seems like weeks, and I think it is time for a newcomer's opinion. I like to read above my station ;-)
"options/a_mapping/key:items/index:0" rather than "python:options['a_mapping']['items'][0]".
They look very similar to me. There is little or no simplification from one to the other. If it is easy to do and shall not impact on the performance of TAL, then go ahead and do it. Otherwise, leave it alone. If you have enough knowledge to create the first one, you can certainly generate the second. The only problem I ever have in this area is knowing when something is too complicated for TAL, and moving that boundary will not help. Often I solve the problem by using a tal:define, which allows the following TAL to cope with the variables I am trying to throw at it. In general this is my rule: do not ask TAL to cope with expressions outside of a define statement. Let it stick with truth and looping, which it is exceptionally good at. Chris> What an extraordinarily good idea! Why has none of us thought of this before? Because it's so extraordinarily /not new/, in the sense that it might be handy when everything else is working but remains unnecessary otherwise. I, for one, remain opposed to the idea that there should be several ways to do the same thing, just because the newer one looks a bit prettier. Newcomers spend time choosing between them to avoid developing a ZClass when they need a Product. Especially when the difference is purely syntactic, nobody bothers to write down that they are purely equivalent. Chris> I wonder what non-python'ers would think? Paul> well, that's a very good and relevant question, but I Paul> doubt we will find them on this mailing list :-) Paul> I would really like to know. I am a relevant newcomer who is getting confused by all the options. I have avoided learning DTML beyond recognising it when I see it, but still find the whole experience quite bewildering at times. It took me the months of UML work to convince my colleague (and introducer) that DTML was a backward step, and only on presenting him with the hard-to-find zpt2dtml conversion guide did I finally make my point that everything was possible without DTML and its implicit acquisition. For my money, get someone to spend time documenting option one first, and explaining why it is useful; then make option two work if there is still demand. It's less sexy, but much more productive. For instance, I spent a long time under the misapprehension that 'options/' was the only way to get python variables into templates, because that's how it shows you in the ZDG. You have an excellent product that is far more powerful than people have realised. <shout>Keep up the good work!</shout> <whisper>which might mean more marketing (documenting) and less programming</whisper> Paul> We all know that Python has a near-unbeatable record Paul> as an easy-to-use, well-designed, and downright fun language. Paul> It has a great reputation as a "first language". I think this is overstating things a little. I came to Zope/python from a background in perl-based Intershop4 and found the transition hard enough. I had printed out the 80 page reference manual before I discovered that it contained not a single python command: only on returning to it after eight months did it begin to make sense, yet wonderful features such as __call__ should be carefully documented as important in Zope Products. Paul> The zope 2 tutorial and most other available documents gave Paul> the impression that you didn't need to learn python to get things Paul> done in Zope. The Zope Book gives the impression that DTML is a poor-man's substitute to ZPT/python, which is why I did not spend time on it. It actually left me with the impression that DTML and python did not really get on. Paul> If you don't know any python, isn't it tempting to write some Paul> icky template code yourself instead of waiting for the code Paul> guy to have time to help you? That's exactly why I wrote custom templates for Intershop 4. It did not support search-within-search, or search-within-category, yet it was clear from the database schema that it should and could with little effort. Luckily the only way to do it was to create the object in advance from the database and loop over it in the presentation. Those of you interested in "options/a_mapping/key:items/index:0" would like their approach. Incidentally, and off topic. I read somewhere here that Zope3 is abolishing implicit acquisition. What should a developer be doing /now/ to avoid obsolescence? Should we use .Explicit throughout for new products, or what? And what does that mean exactly? It's not really documented in the ZDG (maybe a page and a bit), and specifically says (Ch. 3) """In general you should subclass from Acquisition.Implicit unless you have a good reason not to.""" Is Zope3 that good reason? MfG Christopher Boomer, Belfast.
On Tue, Jul 29, 2003 at 09:26:07PM +0100, Christopher Boomer wrote:
The only problem I ever have in this area is knowing when something is too complicated for TAL, and moving that boundary will not help.
In particular, expanding the size of the overlapping gray area will not help.
Often I solve the problem by using a tal:define, which allows the following TAL to cope with the variables I am trying to throw at it. In general this is my rule: do not ask TAL to cope with expressions outside of a define statement. Let it stick with truth and looping, which it is exceptionally good at.
this sounds like good practice.
for one, remain opposed to the idea that there should be several ways to do the same thing, just because the newer one looks a bit prettier.
Yes... a very pythonic philosophy... let's not turn TALES into Perl ;-)
Chris> I wonder what non-python'ers would think? Paul> well, that's a very good and relevant question, but I Paul> doubt we will find them on this mailing list :-) Paul> I would really like to know.
I am a relevant newcomer who is getting confused by all the options. I have avoided learning DTML beyond recognising it when I see it, but still find the whole experience quite bewildering at times. It took me the months of UML work to convince my colleague (and introducer) that DTML was a backward step, and only on presenting him with the hard-to-find zpt2dtml conversion guide did I finally make my point that everything was possible without DTML and its implicit acquisition.
hmm, well to be clear, you're still using implicit acquisition if you say <span tal:content="here/foo"> ... </span> ... and foo is not in the same folder as the template. However, TAL is much better about using explicit namespaces (here, template, container, request) instead of DTML's habit of dumping them all in one pile. Also explicitly saying "python:" when you're writing a python expression, instead of just using quotes. Newbies to DTML often used to talk about "the funny quote syntax", not realizing it was python.
Paul> We all know that Python has a near-unbeatable record Paul> as an easy-to-use, well-designed, and downright fun language. Paul> It has a great reputation as a "first language".
I think this is overstating things a little.
If Zope is your first exposure to Python, I'm not sure if you can appreciate what I mean. :-)
I came to Zope/python from a background in perl-based Intershop4 and found the transition hard enough.
Sure, but I think a lot of that is due to the inherent size and complexity of Zope. Have you ever written some small standalone programs in python? Try it, you'll like it :-) I came to zope from python scripting and I still found it a hard transition: I had to learn the management interface, DTML, acquisition, the security model, how to use the Catalog, how to create a product, etc etc. And believe me, it was harder before Python Scripts were added.
I had printed out the 80 page reference manual before I discovered that it contained not a single python command:
reference manual? which one? The Zope Book? (a fair amount of python is in it these days.) ZOpe Developers' Guide? (lots of python there.)
Paul> The zope 2 tutorial and most other available documents gave Paul> the impression that you didn't need to learn python to get things Paul> done in Zope.
The Zope Book gives the impression that DTML is a poor-man's substitute to ZPT/python, which is why I did not spend time on it. It actually left me with the impression that DTML and python did not really get on.
Hm, maybe we overstated things a bit in the book. :-) DTML and python get along fine; <dtml-in some_python_script> is much the same as <tal:repeat="item some_python_script">. I think DTML is fine as long as you - don't need to edit it with a WYSIWIG tool - don't use the python expression syntax because it's horrid :-) and some people prefer the fact that it's generally less verbose than ZPT.
Incidentally, and off topic. I read somewhere here that Zope3 is abolishing implicit acquisition. What should a developer be doing /now/ to avoid obsolescence? Should we use .Explicit throughout for new products, or what? And what does that mean exactly? It's not really documented in the ZDG (maybe a page and a bit), and specifically says (Ch. 3) """In general you should subclass from Acquisition.Implicit unless you have a good reason not to.""" Is Zope3 that good reason?
Big topic. This may help, though it's currently just an outline: http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PortingAppl... The basic approach that's been suggested is: - Write as much as possible of your product's features in a class that doesn't inherit from *any* zope-specific base classes. - Create a wrapper or derived class that lets you use your class with zope 2. Note that this approach also makes unit testing easier, though you may need to provide stub implementations of other things that your class uses. When it's time for zope 3, most of your work will then consist of rewriting the wrapper (and maybe writing some zcml configuration file). In zope 3, the wrapper should hopefully be simpler than what you need for zope 2. At least, that's the theory :-) -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's ROYAL ALTOIDS TIN! (random hero from isometric.spaceninja.com)
hmm, well to be clear, you're still using implicit acquisition if you say <span tal:content="here/foo"> ... </span> However, TAL is much better about using explicit namespaces Yes, explicitly using implicit acquisition. I'll give you that.
If Zope is your first exposure to Python, I'm not sure if you can appreciate what I mean. :-) Possibly not. I've often been thown into the deep end of projects.
reference manual? which one? The Zope Book? (a fair amount of python is in it these days.) ZOpe Developers' Guide? (lots of python there.) I was referring to Guido's Python Reference Manual, which is less a reference of python modules, rather a reference of how python itself was written. No offence intended. There's lots of python in both Zope books, and I refer to them regularly.
- Write as much as possible of your product's features in a class that doesn't inherit from *any* zope-specific base classes. I can take that advice. Seems reasonable enough, and makes the python more reusable in any case.
I'm currently trying to write the interface to integrate a wholesaler XML response into our database and finding myself falling between XML stools. My notion was to convert it to a local XML format before importing that to the database. I figured that this layer would insulate against change in a similar manner to the above, but it seems that generating xslt programmatically is not something that people are doing much yet. Thanks for your time. Christopher.
- Write as much as possible of your product's features in a class that doesn't inherit from *any* zope-specific base classes.
I can take that advice. Seems reasonable enough, and makes the python more reusable in any case.
I suggest using Persistent as your base class, if you want instances to be persistent. That is, write your basic application as a ZODB application, not a Zope one. -- Steve Alexander
Shane Hathaway wrote:
Literally, "user_files/int:0" says "get item 0 of user_files, interpreting '0' as an integer". Technically, this could be interpreted as "get the attribute named 0 or item 0", but an attribute name must be a string, so implicitly it really just says "get item 0".
We've come up with a number of generally useful prefixes, BTW. Off the top of my head:
call: -- Call a named method int: -- Look up an item by index format: -- Perform simple formatting operations like "format:money" zope: -- Access a big Zope API
This rocks from my perspective :-) Chris
Yes, this would be more comfortable, some of my templates would be cleaner with this feature. You may work this around like this... <stuff tal:define="packed python: someScript(stuff, foo, bar); item1 python: packed[0]; item2 python: packed[1]"> with someScript ending with... return foo, bar I'm interrested into adding some other wishes for the next ZPT versions. Where could those wishes be posted ? Cheers --Gilles
Gilles Lenfant writes:
I'm interrested into adding some other wishes for the next ZPT versions. Where could those wishes be posted ?
This is the place. There's only very limited resources available at Zope Corp to make changes happen right now, so be prepared to help make changes if there's concensus that your proposal should be accepted. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
participants (16)
-
Chris Withers -
Christopher Boomer -
Dieter Maurer -
Evan Simpson -
Fred L. Drake, Jr. -
Gilles Lenfant -
Jean Jordaan -
Jim Penny -
Leonardo Rochael Almeida -
Paul Winkler -
Philipp von Weitershausen -
Richard Jones -
robert -
Shane Hathaway -
Steve Alexander -
Tino Wildenhain