[Zope-dev] local/set (was RE: Zope direction and 2.2 roadmap...)

[Phillip J. Eby]

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?