RacksAndSpecialistsSimplified

Shane Hathaway posted an explanation his understanding of ZPatterns to the zope-dev list on 11 June, 2000. It was very well received, and I've copied it below. SteveA.

Subject: Racks and Specialists Simplified
Date: Sun, 11 Jun 2000 14:33:31 -0600
From: Shane Hathaway
To: "Phillip J. Eby"
CC: [email protected]

Phillip,

I believe I have come to understand the basics of ZPatterns and would like to be sure I understand correctly, as well as help others understand also.

I like to think of a specialist as a filing clerk. A manager comes to the clerk asking for an employee's dental records. Because of the way the company filing system was set up, however, the dental records aren't kept on a single slip of paper. The clerk has to compile the information from the employee's medical and insurance information. The manager doesn't care where the information is coming from, but needs the information on a standard dental record form. So the clerk compiles it and gives the manager the information on the correct form.

In this example, the manager is the "application framework", the file cabinets are "racks", and once again the clerk is the "specialist".

An application framework generally looks in database tables for objects of a specific type. The types of objects may include users, invoices, grades, etc.

A rack is an abstract database table. The data can be stored in ZODB or in some other way, but the point is that a rack is a container for a list of objects of the same type. The basic functionality of a rack can be duplicated by creating a folder and populating it with methods that access a database table, then calling the methods of that folder rather than accessing the database directly.

A specialist essentially provides views, or "sheets", of data from one or more racks. The information on a sheet is compiled from one or more sources and contains the precise information required of the application framework.

If used correctly, the RIPP model makes integration of multiple Zope-based application frameworks relatively straightforward. This means that, for example, a Zope calendar product could gather date information from a Zope logging product, which of course knows nothing about calendars.

Now, the above is what ZPatterns has been claiming all along. But what does it really mean? Well, if you think about it for a moment, the place where people usually want to integrate applications is at the database tables. For example, a database of users contains nothing more than name, login, and password. But what if we want to integrate a user authentication application with a billing application? The billing application looks for a different set of fields, such as account balance, payment due date, etc. and is not interested in the user's password.

The obvious approach is to add more fields to the database table or create another table and join the two. A more flexible approach, however, is to abstract out the database table access, making the storage details irrelevant to the application. This has always been possible, but ZPatterns makes it easier.

The other concepts in ZPatterns expand upon this model. I am still working on grasping them.

ZPatterns also provides the "Plugins" architecture. Racks and specialists are derived from the plugins classes. I see plugins as being a concept that could be used by product authors who don't have a use for racks and specialists. I wonder whether plugins ought to be made a part of standard Zope.

Shane