[Zope-dev] ZClass not in a Product

[Joachim Werner]

> Maybe you search "python.org" for Guido's metaclasses article.
> It tells that a Python class can be both a class and an instance
> and that this view has interesting applications.
>
> You focus on the class aspects of a ZClass (a pattern for creating
> instances providing them with basic common infrastructure),
> while I stress the instance aspects.
>
> The fact, that you can manage ZClasses in the same way as other
> Zope objects, calls for similar structuring possibilities:
> taking them out of the centralized control panel and putting them
> anywhere in the site. That was the starting point of our discussion...

I know about the "duality" of Python classes. I just don't see what I could
really do with a ZClass in the "instance space" (reading this twice, see
below for some possible examples). A totally different aspect is whether
Zope should have something like an in-built support for "virtual instances",
i.e. sub-folders could be like full Zope instances, providing a local
Products directory etc. THAT would make a lot of sense to me. But in general
I am more in favor of getting things OUT of the instance folders than
getting more stuff in.

It makes absolutely no sense to me why the Zope management interface
displays database adaptors, user folders,  and actual content objects all in
the same folder. The only thing these objects have in common is that they
are living in the same namespace. Another problem ist that the Add lists get
longer and longer. So why not have a separate tab for users, content, and
technical things like database adaptors, or SiteRoots? O.k., what we get
then is too many tabs, what there should be a clever way of changing the ZMI
to a multi-level tab concept (main tabs and sub-menus).

To come back to the ZClass question: I see and use them mainly as templates.
That's what they are good for. So they should reside in a template folder.
Right now, this folder is the Products folder. Maybe we need local
Products/Templates folders, so that it is possible to have ZClasses that
just work locally or that overload a base ZClass defined up in the tree. But
what we definitely don't need is freely floating ZClasses.

Another problem is that the ZClass implementation is really "experimental".
They work great, which is a miracle, but they are extremely slow, and a lot
of things you'd need for effectively sub-classing ZClasses from others don't
work. E.g. it is impossible to overload existing properties/porpertysheets,
and acquisition does not work as expected either.

Joachim