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

[Phillip J. Eby]

At 12:39 PM 3/2/01 -0500, Shane Hathaway wrote:
>
>We've been separating concerns in the PTK/CMF for the last year now. 
>We've been moving as many responsibilities of the content objects as
>possible into per-portal "service" objects.  The services provide user
>interface, discussion capability, workflow integration, etc.
>
>In doing so, IMHO we've lost a little simplicity.  In the current way of
>doing things, content objects should not know about their own workflow,
>instead they should be associated with a portal-specific type object and
>the type object is associated with a set of workflows.  And the user
>interface depends heavily on acquisition now.
>
>Now, let's say that instead everything were reintegrated into the
>content objects using aspects.  To retain flexibility, different portals
>would weave the content objects in different ways because of variations
>in user interface, workflow, etc.  Would this be a good application for
>TW?

Absolutely.  And as you've probably guessed, you can insert the
implementations at whatever level of the class hierarchy - insert global
policies into a base ContentObject, override them at a more detailed level,
whatever.


>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.

I haven't given a whole lot of though to through-the-web use of TransWarp's
AOP stuff; I've mainly thought of it as being a "Product"-level tool.  But
I imagine you could perhaps make some sort of "ZAspects" (ala ZClasses)
that wrap through-the-webness onto aspects.  (Of course, if you can do
through-the-web modules, no special magic is required.)

Actually, any Python class or ExtensionClass can be used as part of a TW
aspect, so you could in fact use ZClasses as part of an aspect right now,
if you wanted to.  Handling the class hierarchy of a ZClass could be
tricky, though, if you wanted to be able to deal with them as a class
family.  ZClasses have so many parent classes by default.

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.