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.