Web tool kit : pro - cons ?

[vincent_delft]

I'm looking for a Web Tool kit to build web pages with the following
criteria (in priority order) :
- easy to use, develop (reuseability of code, ...)
- flexible (ideally should run with Python CGIHTTPServer and/or with Apache
(with or wihout mod_python)
- possibility to have load balancing and/or caching (for very high loaded
web pages)

I've founded lot of tools ...

I've read the doc of most of them, I've tested some of them.
But, is there anyone "experience d user" who can give the pro-cons for each
of those solutions ? (or propose an another)

Is there a site who list the main charateristics of each of those Web tool
kit ?

Thanks
Zope (www.zope.org),
SkunkWeb (http://skunkweb.sourceforge.net/),
Quixote (http://www.mems-exchange.org/software/quixote/),
Twisted (http://www.twistedmatrix.com/)
Albatross (http://www.object-craft.com.au/projects/albatross/)
Cherrypy (...)
pwo (...)
....

[Jeffrey P Shell]

"Remi Delon" <re**@cherrypy. org> wrote in message news:<3f24f3f7@ shknews01>...

The problem is that most people are "experience d 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...

[Ian Bicking]

On Wed, 2003-07-30 at 01:28, Jeffrey P Shell wrote:

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.
Praising SQL Methods? Maybe I've been missing something, but SQL
Methods seem really primitive to me, certainly worse than the DB API
(though I suppose they preceded the DB API). The transaction stuff is
convenient -- if sometimes mysterious (like so many Zope things). But
it's not solving a terribly difficult problem.
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.

PyDO and MiddleKit (Webware's) are both independent of their frameworks
(it's kind of unfortunate that they appear to be tied, though), as are
the other ORMs (like my SQLObject). All three provide something
approximating business objects built around database rows.

My impression of Zope's SQL Methods is that they encourage distinctly
un-OO style of programming, and instead everything is done through a
heap of ad hoc queries and eclectic query results. At least, that's the
code I've encountered, and it's taken discipline to avoid doing the same
thing -- maybe there are better ways to use SQL Methods than what I've
been exposed to. (If so, it would be better if Good Zope Style was
documented, not just learned through wisdom born of failure -- but I
haven't found that sort of documentation for Zope yet).

Ian

[Jon Ribbens]

In article <24************ **************@ posting.google. com>, Jeffrey P Shell wrote:

I work with some very talented designers. It used to be that they
would give us (the developers) their designs and we'd rip them to
shreds and they could never touch them again. Because now they were
in little bits and pieces and stuffed full of tags-within-tags, with
silly things like 'standard_html_ header' and 'standard_html_ footer'
(never really fitting a technical definition of header once complex
designs enter the equation) making it very painful to apply what they
would thing were rudimentary design changes.

jonpy works around this problem while also avoiding the limitations of
XML. The templates contain no code at all except <!--wt:name-->
"magic comments" and $$name$$ replacements. Both of these survive the
files being mangled by HTML editors and keeping as much as possible
out of the HTML file means that if you get given brand new
from-scratch design it is still a quick job to 're-templatify' the new
HTML.