Garry Saddington wrote:

Tino Wildenhain wrote:

Am Freitag, den 14.10.2005, 20:03 +0100 schrieb Garry Saddington:
Chris Withers wrote:

Garry Saddington wrote:

<select name="groupabbrev">
<dtml-in getpastoralgroups>
<option value="<dtml-var thisgroupabbrev>" <dtml-if expr="groupabbrev==_.str(thisgroupabbrev)"> selected</dtml-if> ><dtml-var thisgroupabbrev></option>

And just for comparison, here's the ZPT:

<select name="groupabbrev"
       tal:define="abbrev context/groupabbrev">
 <tal:i repeat="group context/getpastoralgroups"
 <option tal:define="thisAbbrev group/thisgroupabbrev"
         tal:attributes="value thisAbbrev;
                         selected python:abbrev==thisAbbrev"

Stop using DTML ;-)


This code does not work;-). If I always work in the ZMI and do not collaborate with designers on database web applications where the data is more important than the presentation, can you give me a good reason for not using DTML. I find DTML more intuitive than ZPT and once you get the hang of the namespace magic thing it is not that bad. The ZPT code above seems to me more complex and it has defined two new variables, whereas the DTML only has two variables
and a string conversion.
ps. I would use ZPT if I could see a valid reason to do so.

The example above is unfortunatly a bit bad from app design view.
You should either do the comparison in your ZSQL Method
or wrap the call to the ZSQL method in a simple python script.

Then all your ZPT reduces to:

<select name="groupabbrev">
<option    tal:repeat="group here/getpastoralgroups"
   tal:attributes="value group/groupabbrev; selected group/selected"
   tal:content="thisgroupabbrev"> Example </option>

Which is imho much better to read then the code above.
All you need to do is to deliver True/False, None/Something
for the "selected" field.
Not doing the comparison in your Template (no matter if DTML
or ZPT) really makes live easier.

You should try to get your Application right independend of
any HTML output. (e.g. you can call the scripts/ZPTs directly
to find out whats going on)

Tino Wildenhain

The comparison is dynamic. The user selects an option, that option is passed to a formhandler and hence back to the referring method. How could I not do the comparison in this method? If it could be done in a python script as you say, why should I inject another layer of complexity into my application when the one dtml method will do the job? imho such a problem as selected in selects should have a well documented solution as many developers will need it and why should each one have to find the solution for themselves? I think Zope is the most important technology on the Internet at present, with the possibility to become really huge, but if every developer has to search so hard for solutions as I have had to, it will forever be a niche product.


You argue sucessfully re: DTML vs ZPT on some of the grounds you articulate.
Although the particulars of your app are not so significant.

Calls to python scripts hardly add complexity - its just the opposite.. Have you noticed a simpler language than python? An important issue in my view - is something unexpected to new ZPT users: superior design patterns - especially if you take advantage of Macros and Slots.

If you are mid developement i wouldnt suggest making the change now. But I do suggest you consider using ZPT when you can - maybe with simpler modules at first. BTW this very same dispute came up a few months ago and you might google for it.


Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to