At 04:15 PM 12/9/99 -0500, Brian Lloyd wrote:

I will definitely be interested in feedback from Zopistas on the effect of PMs on the sort of problems that tags like "local" and "set" propose to solve.

Well, for the situations I wrote local/set for, PythonMethods will have zero impact. Here's an example of the type of situation I use local/set for: <!--#local bgcolor="'something'"--> <!--#if somebusinessrule_or_object_property--> <!--#set bgcolor="'somethingelse'"--> <!--#/if --><!--#var standard_html_header--> HTML Code that uses bgcolor variable in a variety of ways <!--#var standard_html_footer--><!--#/local--> For a PythonMethod to help with something like this, it would have to embed knowledge of HTML-ish things (like color codes). IMHO, DTML methods are supposed to deal with HTML, PythonMethods should deal with business rules. Can you do the above without local and set? Well, you could use REQUEST.set, which, IMHO, is an ugly hack, because it forces the use of a global variable. What if a Product does this and overwrites a REQUEST field that you wanted? It's just plain bad design to use global variables when what you want is a local one. You could do this by breaking up your DTML page into smaller methods, instead, and do something like: <!--#if somebusinessrule_or_object_property--> <!--#let bgcolor="'something'"--><!--#var therealpage--><!--#/let--> <!--#else--> <!--#let bgcolor="'somethingelse'"--><!--#var therealpage--><!--#/let--> <!--#/if--> But this is only (barely) reasonable if one such variable is involved, and doubles the number of methods needed to do something [that should be] quite simple. Now try it with a background color and a couple of different icons, controlled by different properties/methods of the object being rendered. It's not only unreasonable, it's impossible without duplicating logic in ridiculous nestings. Similar issues can come up when you need to conditionally include tables in the FROM clause of an SQL query being generated in DTML. IMHO, PythonMethods won't fix any of these issues. But local/set are useful for any DTML situation where one or more variables need to be set conditionally and then reused throughout the rendering. And, they make DTML easier to explain to those new to Zope. I can't tell you how many times I've had somebody starting with Zope ask me, "So how do I make a variable?" because they were trying to do something like my examples above. (And who then made a nasty face at me when they were presented with the REQUEST.set and "split your page" 'solutions'.) So my take on it is that local/set are needed to improve DTML reusability independent of the presence of PythonMethods. But you probably already knew that. :)

The subject of DTML is a volatile one at the moment, as I'm sure you've seen from the list :) One of the big goals for 2.2 is to see how effective the integration of Python Methods is at reducing the necessity for complexity in DTML. The hope is that PMs will help reduce the need to introduce ever more constructs into DTML, so I plan to wait a while so that we can evaluate the results of the PM effort before adding anything more to the DTML core.

It would be nice to have a clear "yes" or "no" answer sometime soon, though, so that if "local"/"set" aren't going to go in the official distro I can pull them out as a seperate module from "let", for easier distribution of my projects at work. Also, wrt "ever more constructs", I don't believe there are any new constructs to add, since with the addition of local/set, DTML would have effectively the same set of constructs that Python does for bodies of code. What else would one add?