Nicolas Gouzy wrote:
I think this code works :
<select name="groupabbrev"> <dtml-in getpastoralgroups> <option value="<dtml-var expr="_['sequence-item']">" <dtml-if expr="groupabbrev==_['sequence-item']"> selected</dtml-if> ><dtml-var expr="_['sequence-item']"></option> </dtml-in> </select>
-- Nicolas Gouzy nicolas.gouzy@gmail.com
This producing the following result, is this what it should do? <select name="groupabbrev"> <option value="<Shared.DC.ZRDB.Results.r object at 0x43aa7c0c>"><Shared.DC.ZRDB.Results.r object at 0x43aa7c0c></option> <option value="<Shared.DC.ZRDB.Results.r object at 0x43f95824>"><Shared.DC.ZRDB.Results.r object at 0x43f95824></option> <option value="<Shared.DC.ZRDB.Results.r object at 0x43aa7c0c>"><Shared.DC.ZRDB.Results.r object at 0x43aa7c0c></option> <option value="<Shared.DC.ZRDB.Results.r object at 0x43f95824>"><Shared.DC.ZRDB.Results.r object at 0x43f95824></option> </select> regards Garry
Garry Saddington wrote:
Nicolas Gouzy wrote:
I think this code works :
<select name="groupabbrev"> <dtml-in getpastoralgroups> <option value="<dtml-var expr="_['sequence-item']">" <dtml-if expr="groupabbrev==_['sequence-item']"> selected</dtml-if> ><dtml-var expr="_['sequence-item']"></option> </dtml-in> </select>
-- Nicolas Gouzy nicolas.gouzy@gmail.com
This producing the following result, is this what it should do? <select name="groupabbrev"> <option value="<Shared.DC.ZRDB.Results.r object at 0x43aa7c0c>"><Shared.DC.ZRDB.Results.r object at 0x43aa7c0c></option> <option value="<Shared.DC.ZRDB.Results.r object at 0x43f95824>"><Shared.DC.ZRDB.Results.r object at 0x43f95824></option> <option value="<Shared.DC.ZRDB.Results.r object at 0x43aa7c0c>"><Shared.DC.ZRDB.Results.r object at 0x43aa7c0c></option> <option value="<Shared.DC.ZRDB.Results.r object at 0x43f95824>"><Shared.DC.ZRDB.Results.r object at 0x43f95824></option> </select>
Like I said: be careful about what comes out of getpastoralgroups. These are Result objects, not strings. Like any result objects, they store data in attributes with the same name as the row that came out of the SQL results. You must use a row in your comparison: a Result object can never be equal to a string. --jcc -- "Building Websites with Plone" http://plonebook.packtpub.com/ Enfold Systems, LLC http://www.enfoldsystems.com
J Cameron Cooper wrote:
Garry Saddington wrote:
Nicolas Gouzy wrote:
I think this code works :
<select name="groupabbrev"> <dtml-in getpastoralgroups> <option value="<dtml-var expr="_['sequence-item']">" <dtml-if expr="groupabbrev==_['sequence-item']"> selected</dtml-if> ><dtml-var expr="_['sequence-item']"></option> </dtml-in> </select>
-- Nicolas Gouzy nicolas.gouzy@gmail.com
This producing the following result, is this what it should do? <select name="groupabbrev"> <option value="<Shared.DC.ZRDB.Results.r object at 0x43aa7c0c>"><Shared.DC.ZRDB.Results.r object at 0x43aa7c0c></option> <option value="<Shared.DC.ZRDB.Results.r object at 0x43f95824>"><Shared.DC.ZRDB.Results.r object at 0x43f95824></option> <option value="<Shared.DC.ZRDB.Results.r object at 0x43aa7c0c>"><Shared.DC.ZRDB.Results.r object at 0x43aa7c0c></option> <option value="<Shared.DC.ZRDB.Results.r object at 0x43f95824>"><Shared.DC.ZRDB.Results.r object at 0x43f95824></option> </select>
Like I said: be careful about what comes out of getpastoralgroups.
These are Result objects, not strings. Like any result objects, they store data in attributes with the same name as the row that came out of the SQL results.
You must use a row in your comparison: a Result object can never be equal to a string.
--jcc
I have solved this with the following, I hope it may be of help to others: ZSQL: select groupabbrev as thisgroupabbrev from pastoralgroup 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> Thanks for all your help Garry
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 -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
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.
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
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 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
Garry Saddington wrote:
The comparison is dynamic.
Ah, so thisgroupabrev comes from the request? See? I could never have known that from JUST reading the DTML. In ZPT, it would have been request/thisgroupabrev and all would have been clear.
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?
In your ZSQL method, you have access to the REQUEST, so you can build your SQL using a <dtml-if>, and you love dtml right? ;-)
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?
There's probably a How-To somewhere on this... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
New COREBlog 1.2.1 install on Zope 2.7.5 on RHE3 Linux. I can add an instance of a blog and create categories and change settings. Adding an entry gives a name error: Traceback (innermost last): * Module ZPublisher.Publish, line 101, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module App.special_dtml, line 62, in __call__ * Module DocumentTemplate.DT_String, line 474, in __call__ * Module OFS.DTMLMethod, line 137, in __call__ <DTMLMethod instance at b51c8350> URL: http://xxxxxxxxxxxxxxxx/blog/entry_html/manage_main Physical Path:/blog/entry_html * Module DocumentTemplate.DT_String, line 474, in __call__ * Module OFS.DTMLMethod, line 137, in __call__ <DTMLMethod instance at b51c82f0> URL: http://xxxxxxxxxxxxxx/blog/entry_body/manage_main Physical Path:/blog/entry_body * Module DocumentTemplate.DT_String, line 474, in __call__ * Module DocumentTemplate.DT_Util, line 198, in eval __traceback_info__: month_created * Module <string>, line 0, in ? NameError: name 'year_created' is not defined Just curious if anyone else has seen this? Thanks Allen
Allen Schmidt wrote:
* Module DocumentTemplate.DT_String, line 474, in __call__ * Module DocumentTemplate.DT_Util, line 198, in eval __traceback_info__: month_created * Module <string>, line 0, in ?
NameError: name 'year_created' is not defined
Nope, might be time to contact the product author... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Garry Saddington wrote:
This code does not work;-).
That, in itself, as an argument for using ZPT. The reason it doesn't work is probably because of some subtlety in name lookup of your DTML method. Showing DTML to other people, say, on a mailing list, is much harder to grok than a ZPT, where at least you can be asked "what is context in this scenario? container? etc". Tino also hit the nail on the head: if your ZPT seems complexm you're trying to do too much in your presentation layer. Since all DTML is butt ugly and overly complex, you don't get much help with this ;-)
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.
Wow, only a true DTML user could come up with a sentence that convoluted ;-)
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,
Explicit is better than implicit. Try explaining what <dtml sequence-item> means to me, and why it should work ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (6)
-
Allen Schmidt -
Chris Withers -
David H -
Garry Saddington -
J Cameron Cooper -
Tino Wildenhain