Web tool kit : pro - cons ?

[Jeffrey P Shell]

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 ( 
http://hathaway.freezope.org/Software/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 
<http://www.martinfowler.com/eaaCatalog/>`_


> 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).

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/
http://notype.com/drones/artists/eucci.html

RIVE | http://notype.com/rive/
GDBODYCOUNT | http://notype.com/rive/static/024/