Chris Withers wrote:

Just a quickie:

If, as the the ZPatterns Wiki states, 'Specialists are not classes', then why is there a 'Specialist' python class in the ZPatterns distribution?

ZClasses are coded (implemented) using Python classes, and each instance of a ZClass represents a particular application-level class in Zope: DTML Methods are coded (implemented) using Python classes, and each instance of a DTML Method represents a particular application-level method in Zope. Specialists are coded (implemented) using Python classes, and each instance of a Specialist represents a particular ZPatterns Specialist object in Zope. I think you're getting your levels of abstraction confused with your meta-levels of abstraction :-) -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net

At 11:54 AM 7/3/00 +0100, Chris Withers wrote:

Just a quickie:

If, as the the ZPatterns Wiki states, 'Specialists are not classes', then why is there a 'Specialist' python class in the ZPatterns distribution?

Specialists are instances of the class "Specialist". They are not themselves classes. The reason for emphasizing that point is that it is a common misconception of people beginning to use the ZPatterns design approach - they conflate or confuse specialists with the class of the things which they intend to use the specialist to gain access to. In other words, they assume that a specialist called "Customers" would always manipulate "Customer" instances, when in fact it might manipulate "SkyDiver" instances. Most of the point of having a specialist is to have a binding point which allows you to decouple your intended use of a thing, from the specific implementation of it. If one misses this point, one will be blind to a wide variety of ZPatterns' useful applications, and at the same time likely to ask why both Racks and Specialists are needed. They are both needed because the Specialist deals with a particular problem-domain aspect of a thing, and the Rack deals with implementation aspects.