Web tool kit : pro - cons ?

[Jeffrey P Shell]

"Remi Delon" <remi at cherrypy.org> wrote in message news:<3f24f3f7 at shknews01>...
> The problem is that most people are "experienced users" with only a few of
> the frameworks.
> In order to find out all the little caveats of a perticular framework, one
> has to use it for quite a big project (I'd say at least 6 months).
> I don't think any of us have developed such big projects with more than,
> say, 2 or 3 python frameworks. (in my case, I've only used Zope and CherryPy
> for "real" applications. I've only "played" with the other frameworks).
> This is why it is hard to have one person make a comparison of all the
> frameworks ...

That's very true.  I've been using Zope, Principia, and Bobo almost
back to their inception, and can't even grok other systems now.  No
offense to CherryPy or any of the other ones.  But once you get
proficient in a tool, it's hard to spend time with another when time
is..  Well.  What is time and who has it anyways?  :)

I've played with a couple of other Python web frameworks, I've even
written my own (way back in the day when WebObjects was the only major
app server on the market and *everything* else was home grown, and
Java was still a cute way to add animation to web pages ;).  But aside
from the big jump to learning Zope 3 - I know I don't see any time in
my future for doing a serious (ie - more than 'hello world' or
'guestbook') evaluation of anything else.  :\.

In response to the original question - things that I would use when
evaluating kits today is community size, maturity, etc.  There are a
lot of "cool little idea" web kits that never reach completion, or
anything close to it (again - having written one, I know).  Some
projects have been around for a while and have yet to reach a '1.0'
milestone.  Some of those may just be reaching for perfection.  Others
are left to languish while the core developers have to work for a
living, or find other solutions.  Others may be in a state of 'yeah,
the current version is good enough', but a real 1.0 release never
quite seems to get made.  For the past few years, I've made the SCM
decision for myself to never run on beta software, and seldom use
pre-1.0 software, no matter how good it may be, because we've got
dependability requirements from customers that we have to ensure are
met.  And software that looks immature generally gets ranked low on
the list of evaluations.  (of course, having a low quality 1.0 release
is not a good idea either ;)

Quixote and CherryPy both deserve attention for their templating
systems.  I like what I've seen of each more than the many variants of
"Python Server Pages" out there that try to embed Python in HTML
(Python's block structure just makes this already messy style
messier).

Database Abstraction is another key issue.  Zope gets points here not
only for the built in ZODB database, but for SQL Methods / Database
Adapters.  There is nothing in Zope that is tied to Postgres, MySQL,
Oracle, Sybase, SQLite, etc.  Yet it's always been able to use any of
them since before it was Zope.  There's just a nice simple abstraction
layer that one seldom has to think about.  Other tools try the O-R
mapping route for abstraction with varying degrees of success. 
SkunkWeb has PyDO, WebWare has one (I can't remember its name right
now).  Zope's model is nice because it's not intrinsic to Zope that
you use SQL - it's just a nice model to plug into if you need it, when
you need it.  I don't know how other toolkits stack up here.  Some may
just say "go find a Python adapter that works for you and do what you
want with it", which seems to be as good of a way to go as any.

Enterprise scalability could be another factor.  SkunkWeb has
aggressive caching and tight integration with Apache as one of its
features for delivering dynamic chunks of content under high load. 
Zope has its built in transaction system, which makes database work
nice.  Database adapters and other objects can integrate themselves
into this system to ensure that either everything succeeds and gets
written, or everything fails and rolls back, and you're not stuck with
some data in one database but none in another (it's only as infallible
as the systems that support it.  Thank gods for InnoDB in MySQL!). 
Transactions are automatic (but can be handled manually, if desired) -
a web request begins a transaction, and a successful writing of the
response commits it.  Any exceptions raised abort it.  This becomes
one of those little subtle platform niceties that you forget about but
are eternally grateful for.  Usually ;).  Other toolkits may vary - it
depends on what itch they were initially trying to scratch when they
started.  The transaction stuff in Zope goes back to Bobo and the
early BoboPOS (which became the ZODB) because of the work I assume
Digital Creations was doing with databases.  Having gone through the
pain of half written text files generated by mediocre self-written CGI
scripts, this became an early favorite feature :).

In any case, this is just my evaluation list as it would stand today,
given my experiences over the last couple of years.  I don't know how
rosy Zope would come up today if I were evaluating different
frameworks under this criteria - I always think it would be nice to
have time to really step back and evaluate some different options, if
only to get a fresh perspective (kindof like taking some time to
evaluate Ruby might give one a fresh perspective on programming
Python).  But - there's just no time in the schedule to justify such
an undertaking, for better or for worse...