[Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
On Wed, 30 Jul 2003 12:13:41 -0500 Evan Simpson [EMAIL PROTECTED] 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 - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
On Wed, 30 Jul 2003 15:59:47 -0500 Evan Simpson [EMAIL PROTECTED] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 [EMAIL PROTECTED] 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) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
On Tue, 29 Jul 2003 14:27:34 -0400 Paul Winkler [EMAIL PROTECTED] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: TALES idea: tuple unpacking
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 divarg/div div3.40/div divMy Title/div divMy Title/div divpemfoo/em/p /div divskeleton/div divyes/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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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. shoutKeep up the good work!/shout whisperwhich 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. ___
Re: [Zope-dev] Re: TALES idea: tuple unpacking
[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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
On Tue, 29 Jul 2003 16:43:21 -0400 Shane Hathaway [EMAIL PROTECTED] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 gt; 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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/PortingApplications 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
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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: quot;abcquot; / 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 gt; 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#45;-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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
On Tue, 29 Jul 2003 17:04:46 -0500 Evan Simpson [EMAIL PROTECTED] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
On Tue, 29 Jul 2003 17:51:56 -0400 Shane Hathaway [EMAIL PROTECTED] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 pgp0.pgp Description: signature
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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=textTitle 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) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
On Wed, 23 Jul 2003 10:00:37 -0400 Shane Hathaway [EMAIL PROTECTED] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
(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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )