a metric for killing DTML.
Like any site that's been around for a while, we've got a lot of DTML that shouldn't be DTML. We're gradually killing it, but we're looking at detecting stuff that _shouldn't_ be in DTML. One metric that's come up is "any DTML method that has 3 or more calls to REQUEST.set() is probably up to no good." Have other people found other useful rules of thumb about when to avoid DTML? Anthony
Anthony Baxter wrote:
Have other people found other useful rules of thumb about when to avoid DTML?
If it's anything other than presentation logic, fire the person who wrote it. Anyone got a job? ;-) Seriously though, I class anything that uses the "" or expr= as in need of a rewrite. cheers, Chris
i usually consider anything in DTML that does not render a page but acts as some kind of intermediate (like form handlers etc) to be prime candidates for converting to python scripts. as far as the "REQUEST.set-sledgehammer" goes, most of its uses can be replaced by dtml-let, which has the added advantage that you can look at the code and see where a variable came from much faster than scanning all code for REQUEST.set. maybe it's just me, but i consider REQUEST.set bad style that should be used only if nothing else works. jens On Thursday, November 1, 2001, at 02:13 , Anthony Baxter wrote:
Like any site that's been around for a while, we've got a lot of DTML that shouldn't be DTML. We're gradually killing it, but we're looking at detecting stuff that _shouldn't_ be in DTML. One metric that's come up is "any DTML method that has 3 or more calls to REQUEST.set() is probably up to no good."
Have other people found other useful rules of thumb about when to avoid DTML?
Anthony
* Jens Vagelpohl <jens@zope.com> [011101 12:44]:
as far as the "REQUEST.set-sledgehammer" goes, most of its uses can be replaced by dtml-let, which has the added advantage that you can look at the code and see where a variable came from much faster than scanning all code for REQUEST.set. maybe it's just me, but i consider REQUEST.set bad style that should be used only if nothing else works.
I dislike the 'set' hammer too, but there's one scenario in which it seems to be unavoidable: if you need to set a variable which must be accessed from several templates. For example, I may have a navigation bar in one template, the colour of which I want to change depending on tests which take place in a content template. Since <dtml-let> can't span more than one template, is there any other way of manipulating a global namespace in the context of a single request? seb
On Thursday, November 1, 2001, at 02:13 , Anthony Baxter wrote:
Like any site that's been around for a while, we've got a lot of DTML that shouldn't be DTML. We're gradually killing it, but we're looking at detecting stuff that _shouldn't_ be in DTML. One metric that's come up is "any DTML method that has 3 or more calls to REQUEST.set() is probably up to no good."
Have other people found other useful rules of thumb about when to avoid DTML?
seb, the scenario you describe seems to introduce dependencies from one template to another that are only satisfied by explicit code in one template. this is one of the places where REQUEST.set is probably the only way. i personally try to avoid dependencies like that, unless the dependency is on data that is available without the author's explicit intervention (e.g. stuff that is available through REQUEST, anyway). that's why i had not even thought about REQUEST.set in that situation. have you thought about refactoring the code to break this dependency? if you have control over python code it is possible to move the test that gives you the variable you want to place into REQUEST into python and make it cheaper to do the test. then you can test in both places and thereby break the dependency. jens On Thursday, November 1, 2001, at 09:02 , seb bacon wrote:
* Jens Vagelpohl <jens@zope.com> [011101 12:44]:
as far as the "REQUEST.set-sledgehammer" goes, most of its uses can be replaced by dtml-let, which has the added advantage that you can look at the code and see where a variable came from much faster than scanning all code for REQUEST.set. maybe it's just me, but i consider REQUEST.set bad style that should be used only if nothing else works.
I dislike the 'set' hammer too, but there's one scenario in which it seems to be unavoidable: if you need to set a variable which must be accessed from several templates. For example, I may have a navigation bar in one template, the colour of which I want to change depending on tests which take place in a content template. Since <dtml-let> can't span more than one template, is there any other way of manipulating a global namespace in the context of a single request?
seb
On Thursday, November 1, 2001, at 02:13 , Anthony Baxter wrote:
Like any site that's been around for a while, we've got a lot of DTML that shouldn't be DTML. We're gradually killing it, but we're looking at detecting stuff that _shouldn't_ be in DTML. One metric that's come up is "any DTML method that has 3 or more calls to REQUEST.set() is probably up to no good."
Have other people found other useful rules of thumb about when to avoid DTML?
_______________________________________________ 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 )
I think REQUEST.set is fine here. It just has an ugly spelling because nobody will admit it's necessary and everybody pretends they don't do it. ;-)
I dislike the 'set' hammer too, but there's one scenario in which it seems to be unavoidable: if you need to set a variable which must be accessed from several templates. For example, I may have a navigation bar in one template, the colour of which I want to change depending on tests which take place in a content template. Since <dtml-let> can't span more than one template, is there any other way of manipulating a global namespace in the context of a single request? -- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"
[seb bacon]
* Jens Vagelpohl <jens@zope.com> [011101 12:44]:
as far as the "REQUEST.set-sledgehammer" goes, most of its uses can be replaced by dtml-let, which has the added advantage that you can look at the code and see where a variable came from much faster than scanning all code for REQUEST.set. maybe it's just me, but i consider REQUEST.set bad style that should be used only if nothing else works.
I dislike the 'set' hammer too, but there's one scenario in which it seems to be unavoidable: if you need to set a variable which must be accessed from several templates. For example, I may have a navigation bar in one template, the colour of which I want to change depending on tests which take place in a content template. Since <dtml-let> can't span more than one template, is there any other way of manipulating a global namespace in the context of a single request?
1) You can create a page or folder property, and set and access that. 2) You can redesign things so that your templates get called and return values. One of the returned values could be that color. Cheers, Tom P
I wrote -
[seb bacon]
* Jens Vagelpohl <jens@zope.com> [011101 12:44]:
as far as the "REQUEST.set-sledgehammer" goes, most of its uses can be replaced by dtml-let, which has the added advantage that you can look at the code and see where a variable came from much faster than scanning all code for REQUEST.set. maybe it's just me, but i consider REQUEST.set bad style that should be used only if nothing else works.
I dislike the 'set' hammer too, but there's one scenario in which it seems to be unavoidable: if you need to set a variable which must be accessed from several templates. For example, I may have a navigation bar in one template, the colour of which I want to change depending on tests which take place in a content template. Since <dtml-let> can't span more than one template, is there any other way of manipulating a global namespace in the context of a single request?
1) You can create a page or folder property, and set and access that.
I was a bit too hasty here. If a second page request came in at the wrong time, the property could get changed before the first value were used. Session variables would be better.
2) You can redesign things so that your templates get called and return values. One of the returned values could be that color.
Cheers, Tom P
Have other people found other useful rules of thumb about when to avoid DTML?
My guidelines are that dtml is only allowed to do <dtml-with somename> <dtml-with "somename(arg,arg)"> <dtml-in somelist mapping> <dtml-if somename> <dtml-var somename> or &dtml-somename; and variations <dtml-var sometemplate> and that's it. Especially, ANY computation of any sort is forbidden. For every dtml page "mypage" that I have, there is a script "mypage_get" which computes everything, puts it in a a big datastructure (usually a mix of imbricated dictionnaries and lists) and it's called from a dtml-with at the beginning of the dtml page (maybe with parameters). The use of the "mapping" idiom in dtml-with or dtml-in is very very useful. As Seb Bacon mentionned, I still have some REQUEST.set at the beginning of some pages, to initialize variables used in other dtml, but that's because not everything was designed properly I think. Of course I break those guidelines in many occasions, but at least I know I do it and I feel bad about it :) Besides this styles is very straightfoward to translate to ZPT, which is no small advantage. -- Florent -- Florent Guillaume, Nuxeo SARL (Paris, France) +33 1 40 33 79 10 http://nuxeo.com mailto:fg@nuxeo.com
On Thursday 01 November 2001 02:13 am, Anthony Baxter allegedly wrote:
Like any site that's been around for a while, we've got a lot of DTML that shouldn't be DTML. We're gradually killing it, but we're looking at detecting stuff that _shouldn't_ be in DTML. One metric that's come up is "any DTML method that has 3 or more calls to REQUEST.set() is probably up to no good."
Have other people found other useful rules of thumb about when to avoid DTML?
Anthony
Just for something nice to think about... Wouldn't it be cool if somebody wrote a "Zope best practices" guide that encapsulates what language is best to use for what... And when you know that you've hung too far out on a limb that's shakey... Zope gives you so many damned choices... Anyway, one problem is us oldbies who only had DTML or external Python as choices (and we liked it!). I have a tendancy to overuse DTML as a logic language and also Python to generate HTML code... I'm in remedial therapy now, so I hope to break some of those old habits... 8^) /---------------------------------------------------\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association c.duncan@nlada.org \---------------------------------------------------/
Great idea, I'm thinking on that as well, as eg a general practice book. How to mold an application into the ZODB etc. But, unfortunately I think that I'm not the best person for doing this. I think there are people who have much more practice in Zope than I have. I'm not a person who can work the whole day on Zope (unfortunate). But if somebody starts on, I'm always willing to help in the best way I can. Tom. ----- Original Message ----- From: "Casey Duncan" <c.duncan@nlada.org> To: <anthony@interlink.com.au>; <zope@zope.org> Sent: Friday, November 02, 2001 3:06 PM Subject: Re: [Zope] a metric for killing DTML.
On Thursday 01 November 2001 02:13 am, Anthony Baxter allegedly wrote:
Like any site that's been around for a while, we've got a lot of DTML that shouldn't be DTML. We're gradually killing it, but we're looking at detecting stuff that _shouldn't_ be in DTML. One metric that's come up is "any DTML method that has 3 or more calls to REQUEST.set() is probably up to no good."
Have other people found other useful rules of thumb about when to avoid DTML?
Anthony
Just for something nice to think about...
Wouldn't it be cool if somebody wrote a "Zope best practices" guide that encapsulates what language is best to use for what... And when you know that you've hung too far out on a limb that's shakey...
Zope gives you so many damned choices...
Anyway, one problem is us oldbies who only had DTML or external Python as choices (and we liked it!). I have a tendancy to overuse DTML as a logic language and also Python to generate HTML code... I'm in remedial therapy now, so I hope to break some of those old habits... 8^)
/---------------------------------------------------\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association c.duncan@nlada.org \---------------------------------------------------/
_______________________________________________ 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 )
Great idea,
I'm thinking on that as well, as eg a general practice book. How to mold an application into the ZODB etc. But, unfortunately I think that I'm not the best person for doing this. I think there are people who have much more practice in Zope than I have. I'm not a person who can work the whole day on Zope (unfortunate). But if somebody starts on, I'm always willing to help in the best way I can.
Does anyone know wheter the new Zope book (Zope Web Application construction Kit ) has some thougts about this? I cannot find any online contents (and have not found it yet in a local bookstore) Reinoud
Wouldn't it be cool if somebody wrote a "Zope best practices" guide that encapsulates what language is best to use for what... And when you know that you've hung too far out on a limb that's shakey...
Yes DTML is sometimes "evil" when logic, data and layout are melt in a spaghetti mess. At such point it's nearly impossible to find the reason of some bugs. Can you read French ? If yes, read this free chapter from excellent Olivier Deckmyn's book on Zope. It deals with Zope design guidelines, site architecture, security, best choice (ZClass vs Product, DTML vs Python, ZODB vs database...), thinking data then layout... http://www.editions-eyrolles.com/Chapitres/9782212092813/chap14.pdf
participants (11)
-
Anthony Baxter -
Casey Duncan -
Chris McDonough -
Chris Withers -
Florent Guillaume -
Gilles Lenfant -
Jens Vagelpohl -
Reinoud van Leeuwen -
seb bacon -
Thomas B. Passin -
Tom Deprez