Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Web tool kit : pro - cons ?

Reply
Thread Tools

Web tool kit : pro - cons ?

 
 
Jeffrey P Shell
Guest
Posts: n/a
 
      07-30-2003
"Remi Delon" <(E-Mail Removed)> wrote in message news:<3f24f3f7@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...
 
Reply With Quote
 
 
 
 
Ian Bicking
Guest
Posts: n/a
 
      07-30-2003
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



 
Reply With Quote
 
 
 
 
Jon Ribbens
Guest
Posts: n/a
 
      07-30-2003
In article <(E-Mail Removed) >, 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
static cons v/s cons c.lang.myself@gmail.com C Programming 5 12-08-2008 12:48 PM
Is there are good place for me to go investigate the pro and cons. =?Utf-8?B?RnJvZ2xpcHM=?= Windows 64bit 13 11-19-2005 01:09 AM
need recommendations on what brand, specific computer tool kit to buy (physical tool kits, not software kits/suites) Trevor Smithson Computer Information 1 05-27-2005 01:15 AM
need recommendations on what brand, specific computer tool kit to buy (physical tool kits, not software kits/suites) Trevor Smithson Computer Support 5 05-25-2005 07:48 PM
Cisco VOIP - pro/cons? RM VOIP 9 08-28-2003 05:53 AM



Advertisments