Garry Saddington wrote:
Tino Wildenhain wrote:
Am Freitag, den 14.10.2005, 20:03 +0100 schrieb Garry Saddington:
Chris Withers wrote:
Garry Saddington wrote:
DTML:
<select name="groupabbrev">
<dtml-in getpastoralgroups>
<option value="<dtml-var thisgroupabbrev>" <dtml-if
expr="groupabbrev==_.str(thisgroupabbrev)"> selected</dtml-if>
><dtml-var thisgroupabbrev></option>
</dtml-in>
</select>
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"
tal:content="thisAbbrev"/>
</select>
Stop using DTML ;-)
Chris
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.
Regards
Garry
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>
</select>
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)
HTH
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.
regards
Garry
_
Garry,
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.
David
_______________________________________________
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
