[Zope-dev] Re: zope.sqlalchemy

[Laurence Rowe]

Michael Bayer wrote:

> So I will ask you, why can't your application simply have a SalesAddress 
> and an EngineeringAddress class ?   You could even produce them 
> transparently using a custom __new__() method, i.e.
> 
> class Address(object):
>     def __new__(cls, *args, **kwargs):
>         if my_scoped_thing.context == 'sales':
>             return object.__new__(SalesAddress)
>        elif my_scoped_thing.context == 'engineering':
>             return object.__new__(EngineeringAddress)
> 
> this seems extremely straightforward to me as each object, once 
> instantiated is now bound for a specific destination.   It doesnt seem 
> like youd want the *same* Address to be stored in one and then the other 
> in a different instance (that seems *extremely* complex for no good 
> reason).  Isnt explicit better than implicit ?

When the generic address book application is built you don't know what 
the departments will be called or indeed how many departments there are. 
An address book is not be a great example, but I know of intranet portal 
sites where this is a requirement. You want to delegate control to each 
department so you give each department their own instance of the portal. 
You only want to maintain one code base though, and you don't want to 
change it every time someone adds another departmental portal. I'd like 
to be able to create an add form that has fields for application name 
and database url.

This probably seems like an odd requirement -- why not just run multiple 
processes with different configurations -- but it's the way zope has 
traditionally worked. A single process can serve multiple instances of 
the same application (or `site`). When you get up to running tens of 
sites, the memory footprint of Zope2 and Plone  (before the object 
cache) becomes significant.

Laurence