[Zope-dev] TransWarp preview release (AOP tools only)

[Shane Hathaway]

"Phillip J. Eby" wrote:
> 
> At 12:39 PM 3/2/01 -0500, Shane Hathaway wrote:
> >This could be achieved by generating a new Python module for each portal
> >instance, but that would mean sys.modules would have to be pre-loaded
> >with the information about each portal instance and that's not the ZODB
> >way.  It would be better to create a new class loader that can weave a
> >new class on the fly based on persisted component metadata.  Note that
> >class loading is currently quite simple; see
> >lib/python/Zope/ClassLoader.py (sp?).  It could bear some complexity.
> >:-)
> 
> There's actually a simpler way.  Aspect objects can be pickled as long as
> all the objects in them can be pickled.  Which means that as long as all
> their methods are Zope objects, and all the nested classes are also Aspect
> objects, you can save an aspect into the ZODB, and load it at a future
> time.  Further, since adding aspects together makes new aspects, you can
> save the combined aspects, so you only have to perform one call to
> transform the aspect into a family of classes.  That still means some
> load-time complexity, however.

Perhaps... but as I see it, pickling the aspect weaving information into
each object makes it harder to vary the aspect weaving after objects
have been created.  I would want to be able to create a portal, add some
content, then change the aspects that apply to the content after it has
been created.  That means that either the objects have a class
definition that references a centralized component or all content
objects have to be re-woven every time you change the centralized
component.

I'm also planning outside the ZODB.  The goal is to design apps using
pure and simple ZODB and not be required to do anything special to make
it work later with other forms of storage.  Other databases will not be
able to store aspect information.

> It would be interesting if you could take an arbitrary Zope service object
> (like a portal), and go to its "Aspects" tab, and add or remove aspects to
> be woven with its class family.  But I suspect it will be a long time
> before I'll have a need for that personally or professionally, as I am
> focused primarily on TransWarp as a CASE tool and Python application
> toolkit at present.

That's actually the kind of functionality we have now, but we're using
subobjects rather than tabs and we achieve many of the things AOP would
give us through simple delegation.  You should check out the CMF as soon
as the beta is released.

Shane