[TransWarp] lifting class families into Zope

Phillip J. Eby pje at telecommunity.com
Fri Jan 17 18:11:43 EST 2003

At 04:59 PM 1/17/03 -0600, Daniel Mahler wrote:

>I wonder if TransWarp/PEAK offers any way
>to automate the problem of Zopefying preexisting a class library.

Actually, if I understand Zope 3 correctly, it should be possible to do 
this without modifying your source code, apart from perhaps the need to 
inherit from the Persistent base class.  Everything else should be doable 
with adapters, and not having to replace your classes.  But of course, 
that's Zope 3, and perhaps you're talking about earlier Zope versions.

>ie given a set of classes say:
>create a Zope aware varsion of each class
>such that the interfaces line up correctly
>eg ZopeDog().liver would return an instance
>of ZopeLiver rather than Liver.
>The only Zope awareness I want for ZopeDog
>is to inherit from some very
>basic Zope class so that Zope can pass it around
>and possibly put instances in folders.
>This is a fairly mechanical change,
>but seems to require a lot of coding,
>even when using metaclasses and proxies,
>since one must ensure that methods of lifted classes
>return lifted objects.
>The only "quick" way I see of doing it
>is to create a separate copy of the file
>which ensures that classes in it inherit from Zope classes,
>but then I have created a split version of the library,
>rather than a wrapper around the library.
>It seems that something like Don Batory's idea of a mixin layer
>is what I am looking for.

You may want to see if PEAK's module inheritance function does what you 
want.  It lets you create a module that "inherits" all the existing classes 
defined in another module, and then mix in additional code to any of the 
classes.  All functions and methods in the original module are rebound to 
the globals of the new module, so references to classes in the old module 
will refer to to the new classes in the new module.

All you do is add "config.setupModule()" calls to the end of the "old" and 
"new" modules, and in the "new" module, you add code like this:

import oldmodule
__bases__ = oldmodule,

to the top.  Then, if you want to mix something into oldmodule.Animal, just do:

class Animal(StuffToMixIn):

And finish off the module with:

from peak.api import config

That's it.  "newmodule.Dog" will now be a different class than 
"oldmodule.Dog", and its "newmodule.Animal" base will inherit from 
StuffToMixIn.  PEAK recreates the entire class hierarchy for you, with all 
new mixins or functions mixed in.

See "peak.config.modules" for docs, and the peak.config.tests module for 
more examples.

More information about the PEAK mailing list