[Andreas Pakulat]
got a really weird problem here: Error Type: ValueError Error Value: unsupported format character '"' (0x22) at index 45
testing the following python script:
.... fmtstr += ' href="index_html?activetab=%d">%s</a></td>' %(lastelem,tabs[lastelem]) fmtstr += '<td class="headerborderwhite"><img src="%s" ' %(isrc) fmtstr += ' width="10" height="10" style="display:block;width:2em;height:2em"></td></tr></table></td>' fmtstr += '<td style="background-color:#FFFFFF;width:95%"><img src="%s"' %(spsrc)
fmtstr += ' width="3" height="3"></td></tr>'
return fmtstr
Even though Andreas is happy to have found the error, I would like to urge that Python scripts not be used to return markup at all. Instead, return a data structure to the calling page and let the page format the data - either with dhtml or zpt, it doesn't matter in this regard. Writing markup with Python has two big problems, good though Python is - 1) It is really hard to get markup right, as Andreas's example shows. Little errors are easy to make and hard to see. 2) If you want to change the look of the page, you have to rewrite your script, which is painful and prone to the same errors all over again. Using Zope templates, on the other hand, has the following strengths - 1) They are designed exactly for taking data and formatting it into markup, so it is much easier to get the markup right and to spot errors. 2) Page maintenance and changes in appearance are easy to do and do not affect the logic used in the scripts that create the data. All you have to do is have your script return the results of its computation in the form of a string, a list, a tuple, or a dictionary. The template can access all the returned data and format it. I have done it both ways - with pretty complex pages - and I can tell you that it is worth the effort to change your mental habits (which is what it takes) to find ways to just return data and not markup. Let scripts do what they do well, and let the templates do what __they__ do well.
On 23.Mai 2003 - 10:16:40, Passin, Tom wrote:
[Andreas Pakulat]
got a really weird problem here: Error Type: ValueError Error Value: unsupported format character '"' (0x22) at index 45
testing the following python script:
.... fmtstr += ' href="index_html?activetab=%d">%s</a></td>' %(lastelem,tabs[lastelem]) fmtstr += '<td class="headerborderwhite"><img src="%s" ' %(isrc) fmtstr += ' width="10" height="10" style="display:block;width:2em;height:2em"></td></tr></table></td>' fmtstr += '<td style="background-color:#FFFFFF;width:95%"><img src="%s"' %(spsrc)
fmtstr += ' width="3" height="3"></td></tr>'
return fmtstr
Even though Andreas is happy to have found the error, I would like to urge that Python scripts not be used to return markup at all. Instead, return a data structure to the calling page and let the page format the data - either with dhtml or zpt, it doesn't matter in this regard.
I'm relatively new to Zope and ZPT and that way was the easiest to accomplish the task. But I think I'll have a look again and try to get that markup out of the scripts...
1) They are designed exactly for taking data and formatting it into markup, so it is much easier to get the markup right and to spot errors.
But that can make the code very large. The same thing in ZPT has twice the number of lines (and they were longer). And that was the reason for putting it in a script, as I started with vi as editor, but that's history now ;)
2) Page maintenance and changes in appearance are easy to do and do not affect the logic used in the scripts that create the data.
ACK Andreas -- Executive ability is prominent in your make-up.
1) They are designed exactly for taking data and formatting it into markup, so it is much easier to get the markup right and to spot errors.
But that can make the code very large. The same thing in ZPT has twice the number of lines (and they were longer). And that was the reason for putting it in a script, as I started with vi as editor, but that's history now ;)
That's the price you pay for abstraction. If you're allergic to extra work (and who isn't?) just think of it as removing the need for extra work in the future. (It's actually not so much extra work as it is extra typing, which isn't so bad.) If you're not worried about the future, then throw all the markup in code that you want. --jcc
participants (3)
-
Andreas Pakulat -
J Cameron Cooper -
Passin, Tom