Web tool kit : pro - cons ?
Jeffrey P Shell
jeffr at euc.cx
Wed Jul 30 18:00:35 CEST 2003
On Wednesday, July 30, 2003, at 09:16 AM, Ian Bicking wrote:
> 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.
Object Relational mapping is a terribly difficult problem, and SQL
Methods do not attempt to solve that. But SQL Methods are *great* for
reading data, and for composing complex queries. A fair amount of
applications (at least, older school applications) for the web,
particularly intranets, have been about publishing the RDBMS data on
the web. That's what SQL Methods do best.
When it comes to DML statements, they're not stellar. If you're using
an RDBMS as a primary persistence system, then yeah - a lot more work
can be involved. I've started writing around this in a lot of my Zope
applications with a simple core framework to deal with basic CRUD
(Create/Read/Update/Delete) statements where complex queries (usually
only needed on reads) aren't required.
>> 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.
They all put the model too close to the Python code for my personal
comfort. Sometimes that's good. Other times, not so much.
A couple of more interesting systems are Modeling (
http://modeling.sf.net/ ) and Ape (
Ape is a really cool system - but (in current release) you do lose any
benefits of the RDBMS (primarily, advanced queries) in favor of a tight
abstract persistence system. It's tied to Zope and the ZODB at present
(it allows installation of other ZODB storage types), but I think there
are plans to make it more independent (at least from Zope).
Ape keeps all of the collaborating components related to persistence
separated from your business/content objects. What this allows for is
the ability to completely change out the storage type. Not just
switching from MySQL to Postgres, but switching from RDMBS backed
storage to file based storages. The mappers and other components are
responsible for marshaling the objects data into something readable by
the target storage type. So unlike previous SQL storage backends for
the ZODB which basically stored Pickled objects, Ape can turn them into
real readable tables and rows. Or it can turn file like persistent
objects like Page Templates, Python Scripts, images, etc, into readable
and editable files on the file system. You can add a new HTML page or
image into a mounted directory under this scheme, and Ape picks it up
immediately. Extra data, such as Properties, are written out to
separate files, and any other data that Ape doesn't understand is
stored as Pickles. It's pretty seamless, and pretty amazing to watch
it in action.
Shane based the designs for ape on patterns from Martin Fowler's
`Patterns of Enterprise Application Architecture
> 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
> code I've encountered, and it's taken discipline to avoid doing the
> 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).
Ad Hoc queries have their place. And SQL Methods return a fairly
optimized stream of read-only objects that behave like Python objects.
Since they're read only, they can be brought into memory more
efficiently than a list of dictionaries, and they don't have to worry
about name collision. SQL Methods also let you attach 'Brains' to
results. A Brain is a class that gets mixed in with the result object
and allows for adding extra business logic (again - read only), which
is a nice way to add extra computational or logical pieces to a record.
Is it a perfect system? No. But neither is O-R mapping. Both have
their place. But either system is better than a lot of what I see in
ASP, PHP, and ColdFusion scripts where a bunch of SQL is splattered
down in the middle of a script or template. SQL and Code mix about as
well in my stomach as HTML and Code. Which is to say - not at all
(unless you're writing a dynamic DML query builder ;).
SQL Methods may not encourage a distinctly OO style of programming, but
they do encourage reuse. And they encourage being written by people
who know SQL well. Some people can write good HTML, some people can
write good Python, some people can write insanely great SQL. SQL
Methods, (old) DTML/ZPT, and Python Scripts/Products were all Zope's
way of allowing people with different strengths be able to collaborate
on web site, rather than just allowing the code geek to be the only one
in control. It's an admirable design decision that you don't see in
many other places.
I think that the Enterprise Objects Framework had some of the same
goals - that a Model (defines the mapping between objects and the
persistence system, typically RDBMS) could be maintained by someone who
was more familiar with data modeling, or with the target database
model, while someone else could worry about the user interface.
J.Shell | Eucci & Co. | http://euc.cx/
RIVE | http://notype.com/rive/
GDBODYCOUNT | http://notype.com/rive/static/024/
More information about the Python-list