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.


  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',, 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

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to