"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