PSP, Cheetah, PTL, ZOPE, etc ...

Sam Penrose sam at ddmweb.com
Thu Aug 2 22:45:37 CEST 2001


It's clear that medium-scale development can be done with any of
these approaches, including the almost plain string substitution that
my shop uses. IMO the differences should be assessed in the light of,
first, the people/organizations doing the work. The more HTML work is
done by non-Python users, the closer to plain HTML the files should
stay. Also, the more idiosyncratic an approach, the greater the future
investment in maintaining knowledge of those idiosyncracies. 
If you have multiple developers working on a project, consider the
system's robustness. If the developer down the hall--or the client
with FTP access--nukes one of your parseable bits, will the page still
load? Our only modification to Python string substitution is to use a
dictionary object that returns an empty string if confronted with a tag
it lacks rather than raising a KeyError. This makes for a lot fewer
server errors. Conversely, it seems to me that embedded Python systems
seem to appeal to programmers who have web sites as part of their
duties and who work alone or in small teams where everyone is expected
to do some of everything and non-programmers are absent.

The next thing to think about, as noted in AMK's comments on Zope at:
<http://www.amk.ca/python/writing/why-not-zope.html>, is the nature of
the job. Embedding logic in display makes sense when the logic is simple
and widespread; less so when you have to birth twelve objects to
display a single, crucial table row. A good if incomplete overview of
these issues by Martin Fowler (author of the excellent book
Refactoring) is available at:
<http://www.martinfowler.com/isa/webServer.html>

FWIW, my biggest objection to templating issues is adding more magic
characters to my systems. At a minimum I use HTML, Python, a
Python-to-SQL translation layer not under my control, SQL, and plain
text (i.e., email). Each of these layers sees most or all of what can be
generated with a keyboard. The solutions to the inevitable conflicts
have to be preserved across dozens of modules, thousands of HTML files,
and several years' worth of employees.




More information about the Python-list mailing list