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
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:. 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 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 )
[Zope-dev] simpler TALES. (was Re: TALES idea: tuple unpacking)
Just to throw my 2c into the fray. ZPT is an HTML/XML template language. But what does that mean, really? IMHO. Template languages are data structure navigation languages, or model navigating languages (EEEK, templates having direct access to the model!). And the should avoid being turing-complete (or make it very inconvenient to use turing-complete functionality) I agree in principle with Paul that we should try to reduce the number of concepts (the difference between attribute, key and index access, parameter-less method calling, etc) that we need to expose to template authors (and I find the idea of removing "python:" from TALES slightly tempting). But right now the choice between adding or not the proposed TALES extensions is a choice between having to explain what all those python concepts mean before or after the poor template guy got confused why certain things don't work as expected: * Why must I use a tal:define="something here/getSomeObject" and later a tal:content="something/someAttribute" instead of just tal:content="here/getSomeObject/someAttribute". * Why does tal:content="request/form/items" don't get me the "items" object that I'm expecting * etc.. In order to get to the ideal world Paul wants (and that I want too), maybe we need to restrict the things that TALES can navigate. That would mean we'd need to chose between TALES path navigating dictionary keys or attribute access, but not both. Also, paths would not be able to call anything in the last segment. On the other hand, we'd need to give python scripters the necessary tools, ex. before ZPT, I used to find it VERY anoying that I had to use the mapping attribute in DTML tags just because I couldn't create MyBrain objects thru python. PythonScripts should be able to generate the same kind of objects that ZCatalog and ZSQL queries generate. But in the end, it might be just too much trouble, and we're better off teaching some python to the template guys. At least it's python, and not Perl, PHP or vbscript. Cheers, Leo -- Ideas don't stay in some minds very long because they don't like solitary confinement. ___ 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: > > ... > ... ok. > However, the following is quite bad: And quite common :-) Browse through some of the CMF skins... > > > > > 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. > > 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. > > > > > > 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: > > 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 )
[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
Shane Hathaway writes: > I'm not quite sure what you're saying. The following fails compilation: > > That's because you've broken the syntax. It should have been: or, more legibly, 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: > > > > ... being converted by buggy XML or HTML software to this (I've seen it > happen before): > > 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: > > > > 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: 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. 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
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: . 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
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 ... ... 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; is much the same as . 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 your class uses. When it
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: 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: ... being converted by buggy XML or HTML software to this (I've seen it happen before): 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: 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, 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: > > ... > ... > > However, the following is quite bad: > > > > Frankly, would not even have occurred to me - I would probably create a tiny Script (Python) en passant, and called it directly, as: . I did not realize that this is deprecated in Zope3. > > This is un-Pythonic in numerous ways. snip > > > 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
If DTML used TALES expressions, it would be just as clean as ZPT. With the one caveat that ZPTs are valid XHTML, while DTML methods needn't balance tags and needn't mark empty tags as such (i.e. "", instead of ""). DTML tags can straddle HTML tags in completely non-XML ways: ""; limiting the tools that may work with DTML.. The "MTOWTDI" pseudo-entity &dtml-dict.key; alternate syntax might also count against cleanliness. That said, I agree that using TALES would be a big win. We try to use it wherever we can! (Not only in ZPTs :) j ___ 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. 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] TALES wish : the "thistemplate" variable
Chris Withers wrote: http://dev.zope.org/Wikis/DevSite/Proposals/MacroParameters I'm swinging round to the ideas behind this proposal having initially been against it. What's the status of implementation? Somewhere in the clouds. :-) Seriously, people seem to be in favor of it, but it's not a pressing need, so no one is working on it (that I know of.) 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
[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: ... ... However, the following is quite bad: 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. 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. 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: 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
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. Keep up the good work! which might mean more marketing (documenting) and less programming 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. _
[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:
...produces:
arg
3.40
My Title
My Title
foo
skeleton
yes
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
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 )
Re: [Zope-dev] Functional testing of export/import?
On Mon, Jul 28, 2003 at 02:49:33PM -0400, Casey Duncan wrote: > You can usually commit a subtransaction to get a _p_jar and oid (I think) set. > You can still abort this at the end of the test to clean up. yep, this seems to work very nicely! Thanks Casey! def setUp(self): ... get_transaction().commit(1) ... def tearDown(self): ... get_transaction().abort(1) ... -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's EXTRA YELLOW BLOWER CHEESEMONGER! (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, 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
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] TALES wish : the "thistemplate" variable
Shane Hathaway wrote: We recently had a discussion about this: http://dev.zope.org/Wikis/DevSite/Proposals/MacroParameters The conclusion we came to is that we need a new kind of construct, tentatively called a "subtemplate". Subtemplates accept parameters and have full control over the variable namespace, including the "template" variable. I'm swinging round to the ideas behind this proposal having initially been against it. What's the status of implementation? 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
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
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
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
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] Object Type Assocation And Death To index_html
Christopher N. Deckard wrote: Can you put us to the underlying code and I'll take a look at what needs to be done? This is something that is going to be very useful to us. Have a trawl through the list archives, I'm afraid I can't remember where the code is... 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] ZCatalog Indexes tab crawls...
Dieter Maurer wrote: But overall, unless you have special (non DC derived) indexes, That can well be the case... Anyway, what are we going to do about this crawling tab? 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 )
