[Zope] selected in select lists
David H
bluepaul at earthlink.net
Fri Oct 14 22:42:41 EDT 2005
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
More information about the Zope
mailing list