[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:
__bases__ = oldmodule,
to the top. Then, if you want to mix something into oldmodule.Animal, just do:
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 information about the PEAK