Web tool kit : pro - cons ?

[Jeffrey P Shell]

On Wednesday, July 30, 2003, at 10:58  AM, Ian Bicking wrote:

> On Wed, 2003-07-30 at 11:00, Jeffrey P Shell wrote:
>>> 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 ).
>
> I don't really see the advantage of Modeling -- it seems terribly
> verbose to me, though I suppose that's because of its origins in
> Objective C.  I don't see any advantage to separating the mapping from
> the class -- it's all code, it's all written by the same people, and if
> you need separate people to handle the pieces and you can't let them
> both work with the same class, either you don't have enough
> communication between people or you are making the whole thing a lot
> more difficult than it should be.  Modeling feels too formal to me --
> more like Java than Python.  A Python ORM doesn't have to be hard.
>
> APE seems like the other side of formal, where it tries too hard to
> seamlessly support every Python object and in the process is just
> another object database (ala ZODB) that happens to be able to use a
> relational database as a backend.

But that's what makes it impressive - it's a fully abstract persistence  
system.  The ZODB is very well designed, and has been in use for a good  
number of years and in many situations.  Ape is a framework that lets  
you customize how that persistence happens.

> A relational database cannot hold arbitrary Python objects unless you
> want to ruin everything that's good about a relational database.  What
> notions of inheritance that can be implemented have significantly
> different semantics than Python inheritance (and composition is usually
> better than inheritance anyway, and that is well supported by  
> relational
> databases).  Attributes aren't columns, Python types aren't database
> types.  Relations are a different environment all around.  I personally
> can't see the use case where you'll want to radically change storage
> mechanisms while leaving a business class alone.  Yes, you may want to
> radically change the storage -- but it only matters that the  
> *interface*
> to that class can stay the same, not that the entire class
> implementation is storage-neutral.

A class shouldn't necessarily care about how its stored.  A contact  
record is a contact record is a contact record.  Storage shouldn't  
factor into the business object at all.  Maybe ties to the persistence  
framework should factor in, but storage is a responsibility of the  
persistence framework.

> That it requires some effort and
> thought to move from an RDBMS to a flat file (for instance) is not a  
> big
> problem in my mind.  Moving from, say, Postgres to MySQL without effort
> *is* nice, and achievable without having separate mapping objects.  I
> think if APE is going to be relational, it has to be more like an ORM.

But Ape is not relational.  It does files extremely well.  I've thought  
about using it do deal with LDAP.  It should take effort to move from  
an RDBMS to a flat file, but that effort shouldn't affect the main  
application classes - that's the responsibility of the persistence  
layer.

In any case, I decided a few months ago to stop chasing the pure O-R  
mapping grail and went with a chain of data-operating business  
components instead of data-backed business objects.  I realized that  
the read/write logic was part of my application more than it was part  
of the core model (the table definitions or LDAP schema), and went with  
an explicit system [1].  It's a similar set of patterns to those used  
by Ape, but implemented further up the application chain.  I recently  
applied the same patterns to LDAP with pretty good results [2].  A  
module called 'forms.py' sits in the package and contains a host of  
Formulator form definitions, LDAP mappers (which set some flags on  
attributes, such as if its a single value and if it should be deleted  
when an empty/nonexistent value is passed to the Gateway which does the  
actual communication to the LDAP server), and - when needed - extra  
PreWrite / PostRead handlers which can apply extra logic to getting  
data for a particular objectClass combination out of the database (such  
as converting a number expressed in bytes to and from Megabytes for  
easier editing).    Most application changes just require tweaking the  
'forms.py' module to add another attribute and a widget/validator for  
it.  So - the mapper file has extra benefits to my applications in that  
I get HTML form building and validation as part of the process.  By  
dropping my earlier requirements of having a 'Contact' class that could  
map 1-1 with a RDBMS (or other system) and instead having a  
ContactMapper (semi-storage specific) and/or ContactSchema (storage  
agnostic - only there to provide rules), I've gotten some fairly robust  
applications that have surprised me (considering how the plan came into  
being and generally executed while watching the Sopranos).

This is a similar system to Zope 3, which separates Schema (used as  
part of the Interface system) from implementation.  Schema definitions  
allow you to write up nice contracts, such as "an 'age' value is an  
integer in the range of 0 - 150".  They're completely implementation  
agnostic (as long as the implementation implements the interface).  I'm  
looking forward to seeing that system settle out - I know it would make  
my LDAP application's schema definitions for Python a lot nicer to look  
at.


[1]  
http://toulouse.amber.org/archives/2003/05/14/ 
component_relational_mapping.html
[2]  
http://toulouse.amber.org/archives/2003/06/26/ 
applying_mapping_patterns_to_ldap.html

J.Shell
Eucci & Co.
http://euc.cx/

Rive, finest recordings since 1994,2003
http://notype.com/rive/