-----Original Message----- From: Michel Pelletier Sent: Tuesday, July 06, 1999 8:08 AM To: 'Alexander Staubo' Cc: 'bruce@perens.com' Subject: RE: [Zope] Using Zclasses
-----Original Message----- From: Alexander Staubo [mailto:alex@mop.no] Sent: Tuesday, July 06, 1999 1:59 AM To: Zope Mailing List (E-mail) Subject: RE: [Zope] Using Zclasses
Sort of; if I have interpreted unofficial statements on the list from DC people correctly, ZClasses replace products in many cases, although very possibly not all; for example, I'm quite certain that most of Confera could have been implemented as a ZClass. Certainly the product API is complex (or undocumented) to an extent which makes ZClass more desirable, moreover from an object-orientated design perspective, products are inferior.
Let me help this discussion with some Jargon Control (tm). Let's step back through the sands of time to Zope 1.10 when ZClasses were just a glimmer in Jim's eye. Then we had Products. Products are basicly Python Packages that let you extend the object space of Zope. If your Product (package) complied with certain rules, it was possible (although not neccesary) for that Product to register with Zope one or more Python classes which Zope could then instanciate via whatever means the Product author wanted (usualy through the management interface, altough it is possible for Python Products to define new DTML tag classes).
Fast forward a few thousand CVS checkins to Zope 2.0.0a. There are still Products and Classes, but now there are two kinds (at a high level) of each. There are still good old fasioned Python Products and Python Classes, but now there are Web Products and ZClasses. To Zope, they are indestiguishable; Products are managed through the same interface, and Classes can be instanciated in Zope. However, quite of bit of the infrastructure of creating a Product that adds Classes to Zope has been abstracted into a web management interface. Nothing has changed at the lower level, a Products job is still to extend the object namespace of Zope, and a classes job is still to define new types of objects. So in light of this, ZClasses are not really meant to 'replace' Products.
What they can replace are certain candidate Python classes. We discovered in much of our development of Products that alot of our code was identical across products. All packages, modules, and classes that played nicely with Zope all played nicely in exactly the same way. In fact, for very simple Products (like the Poll Product) there was nothing the code in the object did that couldn't be done in DTML; the Python code involved was simply a wrapper around a concept, the concept being an object that knows how to hook into Zope. This concept is was spawned ZClasses.
ZClasses are very handy, but they are not superior to Python classes. In fact, they are quite a bit weaker, which is why it is possible for a ZClass to subclass a base class (which may be either Z or Pythonic). This weakness is payed off in spades however, when it comes to designing, managing, and playing with new types of objects in Zope. A 'Product' can now be whipped up very quickly, prototyped and modified all without leaving your web browser.
Your mention of Confera is a good one, because that is the perfect example of a Zope product that can be written with a ZClass, but not entirely. All of the user interface can be designed with a ZClass, but because Confera uses the indexing machinery, at some point the 'ZConfera' author will need to drop down to Python to index the messages. This can be done as external methods, or as a Python class that the 'ZConfera' class subclasses.
Also, the Product API, undocumented though it is, is still a necesary part of serious ZClass design. The benefit of ZClasses is that most of the more mundane and undocumented parts of Product development are made invisible by web products and ZClasses. However, the more interesting parts of the Zope API are still needed for ZClasses to do much of anything useful. Also, ZClasses which subclass something like 'ObjectManager' completely assume that part of the Zope API as their own.
-Michel
(If that is what you asked. If the question was "What is the product interface for?" then the answer isn't "So you can edit properties through the standard management interface," and it isn't "So you can have properties as objects," either.)
-- Alexander Staubo http://www.mop.no/~alex/ "What the hell, he thought, you're only young once, and threw himself out of the window. That would at least keep the element of surprise on his side." --Douglas Adams, _The Hitchhiker's Guide to the Galaxy_
-----Original Message----- From: bruce@perens.com [mailto:bruce@perens.com] Sent: 6. juli 1999 07:26 To: alex@mop.no; zope@zope.org Subject: RE: [Zope] Using Zclasses
From: Alexander Staubo <alex@mop.no>
Your second question is trickier, because Zope does not, afaik, support properties that are objects. It's possible, but I believe you can't edit these properties through the standard management interfaces.
Naievely I ask, isn't that what the product interface is for? I must be missing something.
Thanks
Bruce
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(For developer-specific issues, use the companion list, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )