I want something like this: flag=0 if ...: <dtml-in ...> ... flag=1 </dtml-in> endif if not flag: print something else endif But I can't figure out how to change a variable initialized by <dtml-let flag='0'>. How can I do this? This is really frustrating, I feel like a total idiot asking for help about such a basic thing! Bjorge -- http://www.lstud.ii.uib.no/~s0182/smile/Smiles -- Bjørge Solli - Universitas Bergensis, Norway mailto:Bjorge@Kvarteret.no icq#29210281 MSN:bobelloco@hotmail.com Møllendalsv.19, 5009 Bergen, Norway tel:55202853/91614343
how about: <dtml-call "REQUEST.set('flag', 0)"> <dtml-if "..."> <dtml-in "..."> <dtml-call "REQUEST.set('flag', 1)"> </dtml-in> </dtml-if> <dtml-if "flag == 0"> ... </dtml-if> Is that what you want? I preffer to use REQUEST.set over dtml-let. Rick Bjørge Solli wrote:
I want something like this:
flag=0 if ...: <dtml-in ...> ... flag=1 </dtml-in> endif if not flag: print something else endif
But I can't figure out how to change a variable initialized by <dtml-let flag='0'>. How can I do this?
This is really frustrating, I feel like a total idiot asking for help about such a basic thing!
Bjorge
On Tuesday, July 23, 2002, at 11:35 AM, D. Rick Anderson wrote:
I preffer to use REQUEST.set over dtml-let.
Wow, that's a HUGE improvement over the awkward requirements of dtml-let! I never thought of doing things that way, but it sure makes things a lot easier. I'm a newbie, and am using The Zope Book as my guide. And while I found REQUEST.set described in that book, it was buried in a description of the REQUEST object, and no mention of this technique was made anywhere. Is there another good book you would recommend as a source of good programming practices in Zope? I get the feeling that, like dtml-let, I'm doing things the hard way a lot of the time. ___/ / __/ / ____/ Ed Leafe http://leafe.com/ http://foxcentral.net
I have The Zope Book and The Book of Zope (ISBN: 1-886411-57-3) which is good because it gives a lot of examples, but I'd say that this mailing list has been my best resource by far. The people on here are brilliant and always seem to have time to help. I'm just glad that I could contribute. Rick Ed Leafe wrote:
On Tuesday, July 23, 2002, at 11:35 AM, D. Rick Anderson wrote:
I preffer to use REQUEST.set over dtml-let.
Wow, that's a HUGE improvement over the awkward requirements of dtml-let! I never thought of doing things that way, but it sure makes things a lot easier.
I'm a newbie, and am using The Zope Book as my guide. And while I found REQUEST.set described in that book, it was buried in a description of the REQUEST object, and no mention of this technique was made anywhere. Is there another good book you would recommend as a source of good programming practices in Zope? I get the feeling that, like dtml-let, I'm doing things the hard way a lot of the time.
___/ / __/ / ____/ Ed Leafe http://leafe.com/ http://foxcentral.net
Uh, dtml-let is NOT equivalent to REQUEST.set. This is not an either/or decision here. dtml-let is a namespace operator, much like Lisp's (let ...) operator. Unforunately, most people assume let is like BASIC's let, which is assignment, not namespace creation. To put it another way, DTML does not prevent you from assigning values to variables, but it does nothing to make it easy (like providing syntax). I've always wondered if there was a design decision behind this or just a simple oversight.
-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Ed Leafe Sent: Tuesday, July 23, 2002 9:30 AM To: D. Rick Anderson Cc: zope@zope.org Subject: Re: [Zope] change variable
On Tuesday, July 23, 2002, at 11:35 AM, D. Rick Anderson wrote:
I preffer to use REQUEST.set over dtml-let.
Wow, that's a HUGE improvement over the awkward requirements of dtml-let! I never thought of doing things that way, but it sure makes things a lot easier.
I'm a newbie, and am using The Zope Book as my guide. And while I found REQUEST.set described in that book, it was buried in a description of the REQUEST object, and no mention of this technique was made anywhere. Is there another good book you would recommend as a source of good programming practices in Zope? I get the feeling that, like dtml-let, I'm doing things the hard way a lot of the time.
___/ / __/ / ____/ Ed Leafe http://leafe.com/ http://foxcentral.net
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
On Tuesday, July 23, 2002, at 12:45 PM, Charlie Reiman wrote:
Uh, dtml-let is NOT equivalent to REQUEST.set. This is not an either/or decision here. dtml-let is a namespace operator, much like Lisp's (let ...) operator. Unforunately, most people assume let is like BASIC's let, which is assignment, not namespace creation.
To put it another way, DTML does not prevent you from assigning values to variables, but it does nothing to make it easy (like providing syntax). I've always wondered if there was a design decision behind this or just a simple oversight.
Well, in my case, I am taking values from a form, cleaning them up (removing punctuation from phone numbers, etc.), and then updating a database with these 'processed' values. I changed one of my methods from dtml-let to REQUEST.set, and it worked perfectly while becoming much, much cleaner. So while the two may not be equivalent, they both do what I need, and REQUEST.set is far superior for this. ___/ / __/ / ____/ Ed Leafe http://leafe.com/ http://foxcentral.net
I agree with Charlie, I think DTML has been designed not to make it easy to do any kind of business logic. Zope Page Templates are more recent, and have even less capacity for programming logic. I'm newish to Zope myself, but for any development I do now, I only use DTML for presentation itself. For each page of the site I'm developing, I have a Python script, e.g. calendar_view_handler to take any form inputs from the previous page, use things from the session, call and use ZSQL methods, and put everything I need for the next page, in nice data structures into the request object, then call the DTML method, e.g. calendar_view_display, which only uses DTML variables to loop over data structures, and maybe do simple 'this or that' splits if I absolutely have to. This allows a clean separation of logic and presentation, and means you don't have this constant wrestle against the limitations of DTML. Using Python is actually a lot easier than using DTML - don't be scared by it, it's the easiest language to learn I've come across :) Ben Avery YouthNet UK Ed Leafe wrote:
On Tuesday, July 23, 2002, at 12:45 PM, Charlie Reiman wrote:
Uh, dtml-let is NOT equivalent to REQUEST.set. This is not an either/or decision here. dtml-let is a namespace operator, much like Lisp's (let ...) operator. Unforunately, most people assume let is like BASIC's let, which is assignment, not namespace creation.
To put it another way, DTML does not prevent you from assigning values to variables, but it does nothing to make it easy (like providing syntax). I've always wondered if there was a design decision behind this or just a simple oversight.
Well, in my case, I am taking values from a form, cleaning them up (removing punctuation from phone numbers, etc.), and then updating a database with these 'processed' values. I changed one of my methods from dtml-let to REQUEST.set, and it worked perfectly while becoming much, much cleaner. So while the two may not be equivalent, they both do what I need, and REQUEST.set is far superior for this.
___/ / __/ / ____/ Ed Leafe http://leafe.com/ http://foxcentral.net
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
On Tue, Jul 23, 2002 at 06:17:45PM +0100, Ben Avery wrote:
I agree with Charlie, I think DTML has been designed not to make it easy to do any kind of business logic. Zope Page Templates are more recent, and have even less capacity for programming logic.
I think that was a deliberate decision, to encourage further separation of logic and presentation, possibly inspired by the recurring threads like "How do I do 10,000 things in my DTML document" which inevitably lead to some really confusing dtml code suggestions. Divide and conquer...
I'm newish to Zope myself, but for any development I do now, I only use DTML for presentation itself. For each page of the site I'm developing, I have a Python script, e.g. calendar_view_handler to take any form inputs from the previous page, use things from the session, call and use ZSQL methods, and put everything I need for the next page, in nice data structures into the request object, then call the DTML method, e.g. calendar_view_display, which only uses DTML variables to loop over data structures, and maybe do simple 'this or that' splits if I absolutely have to. This allows a clean separation of logic and presentation, and means you don't have this constant wrestle against the limitations of DTML. Using Python is actually a lot easier than using DTML - don't be scared by it, it's the easiest language to learn I've come across :)
Hear, hear. You're lucky that you got the idea early. I think many Zope newbies are put off by the thought of learning a templating language *and* a programming language. But it's really the right way to approach Zope. Everything becomes so much nicer. Remember, the O stands for Object... and any good object-oriented designer appreciates low coupling and high cohesion. Any Zope developers who don't recognize those phrases are highly encouraged to go look them up. Light bulbs will appear over your head when it sinks in. -- Paul Winkler home: http://www.slinkp.com "Muppet Labs, where the future is made - today!"
To put it another way, DTML does not prevent you from assigning values to variables, but it does nothing to make it easy (like providing syntax). I've always wondered if there was a design decision behind this or just a simple oversight.
It's a design decision, enforced by a "papal edict" (Jim hates REQUEST.set). - C
On Tue, Jul 23, 2002 at 01:17:30PM -0400, Chris McDonough wrote:
To put it another way, DTML does not prevent you from assigning values to variables, but it does nothing to make it easy (like providing syntax). I've always wondered if there was a design decision behind this or just a simple oversight.
It's a design decision, enforced by a "papal edict" (Jim hates REQUEST.set).
Sometimes papal bulls are, in the American slang sense, just bull.
You know, I understand this, to a point. But it does have a very real cost (particularly in DTML), and I think the cost was overlooked because zope.com is so heavily into zope as document management system, rather than an application server. If you are using zope heavily as an application server, you have a very typical pattern of receive form, canonify data (always strip, often take to a particular case), validate data, and store or otherwise process the data. There is no reason to have the canonify/validate steps be part of the processing procedure. Both for reasons of reuse, and general clarity, they really belong in separate methods. But now you have a problem. You have to get the canonified version of the REQUEST data back to the processing method. And I know of (in DTML) no other way than using REQUEST.set. ZPT offers the 'options' namespace, which I try to use exclusively when passing a variable that was not part of the original REQUEST. But, it still feels silly to make a new variable to hold the canonified and validated data, rather than just using REQUEST.set. With hindsight, it might have been nice to have REQUEST be read-only, and something like OPTIONS. OPTIONS would have been a dictionary, initially empty, with a OPTIONS.set method. namespace lookup (in DTML) would always process OPTIONS before REQUEST and before acquisition. This would provide a writeable short-teem dictionary. But, it is too late to think about that now. Jim Penny PS: I have moved pretty much to ZPT these days. I still use DTML, when it is needed, or occasionally when it feels much cleaner. The reason that I moved and stayed is mostly twofold. First, the options namespace is, in fact, a much cleaner solution. Second, path expressions make it relatively easy to use the same form to both accept input and handle errors. This makes it far easier to change things, in that rather than messing with an input form and an error, everything you need is in one place. It feels like zope.com makes a mistake in using the "closing designer to developer loop" as the primary seling point of ZPT. Jim Penny
- C
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
It's a design decision, enforced by a "papal edict" (Jim hates REQUEST.set).
Sometimes papal bulls are, in the American slang sense, just bull.
I agree. Luckily, Zope is extensible to that point that someone can create their own tags to do this. http://www.zope.org/Members/ivo/SetTag
You know, I understand this, to a point. But it does have a very real cost (particularly in DTML), and I think the cost was overlooked because zope.com is so heavily into zope as document management system, rather than an application server.
Errr.. well, we do lots of jobs. Very few of them are document management systems; mostly we build content management applications. I'm not sure what the difference would be, though. Zope is an appserver and we use it as such to build apps.
If you are using zope heavily as an application server, you have a very typical pattern of receive form, canonify data (always strip, often take to a particular case), validate data, and store or otherwise process the data. There is no reason to have the canonify/validate steps be part of the processing procedure. Both for reasons of reuse, and general clarity, they really belong in separate methods.
But now you have a problem. You have to get the canonified version of the REQUEST data back to the processing method. And I know of (in DTML) no other way than using REQUEST.set.
You can pass arguments to DTML methods & documents from both Python Scripts and other DTML methods/documents (as well as ZPT). (re: http://www.zopelabs.com/cookbook/992031125) It's not pretty, but it does work. I think the awful DTML object call signature is at the root of the issue you talk about, otherwise we'd just say "pass it in as an argument" and this issue would disappear. As you say, ZPT offers namespaces for this kind of thing. We'd like to do the same thing for DTML (see http://dev.zope.org/Wikis/DevSite/Proposals/DTMLplusTALES) but the call semantics are so "baked-in" that it would be terribly difficult (maybe impossible) to do so in a backwards-compatible way.
It feels like zope.com makes a mistake in using the "closing designer to developer loop" as the primary seling point of ZPT.
It is a cleaner system, no doubt about that. - C
[Chris McDonough]
To put it another way, DTML does not prevent you from assigning values to variables, but it does nothing to make it easy (like providing syntax). I've always wondered if there was a design decision behind this or just a simple oversight.
It's a design decision, enforced by a "papal edict" (Jim hates REQUEST.set).
I remember a few threads that said that REQUEST.set can give memory leaks. Chris, could you give us the correct story about this? Cheers, Tom P
I remember a few threads that said that REQUEST.set can give memory leaks. Chris, could you give us the correct story about this?
I'd like to, but I'm not certain that I know for sure... adding objects as attributes of REQUEST *shouldn't* cause leak, but there are so many objects that themselves hold a reference to REQUEST in Zope, that it's feared that it's eminently possible to create a circref using REQUEST.set. It would be nice if somebody wanted to spend the time to figure out when and if this could happen. - C
participants (9)
-
Ben Avery -
Bjørge Solli -
Charlie Reiman -
Chris McDonough -
D. Rick Anderson -
Ed Leafe -
Jim Penny -
Paul Winkler -
Thomas B. Passin