Problem: Encapsulation for plugable brains and other purposes are too hard. ZClasses are a global kind of thing that requires going into a separate area of the site which you have to have permission to use. Also I find that I evolve my solutions. I will produce something in folders that works for what I want and then try and generalize it into ZClasses later. However if my solution in the folders itself wants to use classes then the only choice I have is external methods or ZClasses. Solution: Local ZClasses: A ZClass that can be created in any folder and is available with the acquisition path. It can then be used for pluggable brains with sql methods also where the Class can be reached in the acquisition path. e.g. I have a few fancy display methods that I use for display results of a sql query for getting phone contact info e.g. create a vCard for each entry. I create a ZClass with a property sheet matching those returned by the sql method. I create my display methods within this ZClass. I associate the sql method with the ZClass. I call the query with dtml-in. Within the loop I have access to the ZClasses methods. Second solution: Prototype objects: A folder is an object with methods etc. A ZClass is not much different except that it has a constructor and a list of the properties that are always there. With a bit of syntax we could make a local folder into a local ZClass. We just need a method that says, using this folder as a prototype, create me a new object. e.g. <dtml-call "REQUEST.set('myobj',_.new(users_class, name='Dylan'))">. This would effectively make a new non persistent object that inherits from the prototype folder I guess. This could be done with plugable brains as well by just specifying the folder as if it was a class and then new objects would created for each row. If you enable the ability to make these prototype objects persistent then you get the side effect that you can create symbolic links. You can access a whole other acquisition path using inheritance. In fact you could have a property of a folder which is its inheritance objects which you could change over its life time. In fact any object could have this property could affect an objects behavior without moving the object or modifying its underlying classes. Also it would mean overload any kind of object. Just create a folder that inherits from an object or class and add methods. Personally I think the second solution has a lot of merit. What do others think?