Web devel with python. Whats the best route?

Wed Jan 10 01:42:32 EST 2001

In article <mailman.978975978.19612.python-list at python.org>, Moshe 
Zadka <moshez at zadka.site.co.il> wrote:

> On Mon, 8 Jan 2001 17:46:13 +0100, "Alex Martelli" <aleaxit at yahoo.com> 
> wrote:
> 
> > CGI.  Really.  Your admin system doesn't look like the kind of thing 
> > that
> > will be continuously getting multiple hits a second, making CGI 
> > overhead
> > a problem.  If that is the case, CGI is easiest.  *Do the simplest 
> > thing
> > that can possibly work*!
> 
> CGI is not an answer. Perhaps you meant "CGI with lots of little
> print '<HTML>' this and print '<BODY>' that", which is as far from
> the simplest thing that could possible work as possible. Most Python web
> frameworks work just fine from CGI (PSP, WebWare, and even Quixote, I 
> think).
> Those are answers, and very good ones.
> Perhaps even CGI+HTMLgen is an answer, though this might depend on
> personal taste. 
> 
> Of course, the simplest thing that can possible work 
> interface-to-the-browser
> part is of course not even going with CGI, but with inheriting from
> BaseHTTPRequestHandler. Connecting that to something like PSP you
> get a cross-platform solution which is very easy. Connecting it to ZODB
> may be the final piece of the puzzle -- with ZODB and a dash of cookies,
> state management becomes so easy you'll wonder how you did without
> it.
> 
> Of course, to be true to the Python tradition, take the 
> PSPHTTPRequestHandler+ZODB and join the egroup mailing list for Python
> web frameworks developers.
> 
> using-mod_perl+HTML::Mason-and-hating-it-myself-ly y'rs, Z.

As Alex noted, many of us generate HTML template files with embedded 
Python markers, read them in, execute some Python, and print.

My company employs three programmers and an HTML person making Python 
CGI-driven dynamic web sites. Our biggest client does thousands of 
dollars a day in ecommerce, selling over 800 products with a series of 
complications due to the nature of the products and the company's 
business model. Before moving to a TurboLinux cluster for redundancy, 
the ~3,000 line system was pumping out about 25,000 dynamic hits a day 
on a 500 MHz Pentium III with 256 megs of RAM and a 7200 rpm SCSI drive 
running RedHat Linux and Apache. None of the software (ours or 
Linux/Apache) was tuned for performance; the three programmers who wrote 
ours averaged about 6 months of experience. We have had no performance 
problems. I suspect a cluefully-written CGI system could handle at least 
100,000 hits a day on $2,000 worth of hardware, as long as the peaks 
weren't too brutal.

In contrast to Alex's comments, however, we do not place Python 
statements within HTML. We stick with string substitution keys, 
resorting to regular expressions once in a great while. Part of a 
template might look like:

First Name: <input type="text" name="firstName" value="%(firstName)s">
Last Name: <input type="text" name="lastName" value="%(lastName)s">
Street: <input type="text" name="street" value="%(street)s">
...etc....

The script will then read that in and substitute the relevant contact 
info or blank strings, as appropriate. The advantage to the system is 
that we can hire HTML specialists and Python specialists, and teach them 
enough about each other's areas to work together.

For sessions, we use keys placed in HTML. There is an entire framework 
for generating the key at login, check its validity and freshness (keys 
time out after a certain period, typically 30 minutes), and dropping it 
into every link on the page as well as a hidden field for POST 
submissions. Then there are all sorts of silly little routines we have 
for generating pulldown menus, setting radio buttons and checkboxes, 
talking to the database, etc. As an application platform, HTML is 
stateless and UI-impaired, but you can do quite a bit with it. My summer 
project was a content management system for the same client's intranet. 
Also about 3,000 lines, it handles an owner-group-world permissions 
system, calendaring, time tracking, file uploads/sharing, images, 
HTML/plain text, various forms of dynamic site navigation, form creation 
(you can make your own CGIs and receive submissions via email), and 
more. All through plain jane Python CGIs.

The next time someone posts to comp.lang.python telling you you really 
need an Apache module/Zope/whatever to handle that customer feedback 
page, don't believe them.

(Out of all of the projects tracked on Paul's page, the two that 
interest me are Chuck's Webware and Titus' AOL Server thingie. The 
former looks well-designed, and AOL Server, sans Python, has a track 
record of handling extremely high loads gracefully. Note that I haven't 
actually used either and neither appears to be finished.)