History for RacksAndSpecialistsSimplified

??changed:
-
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<br>
    Date:  Sun, 11 Jun 2000 14:33:31 -0600<br>
  From:  Shane Hathaway<br>
    To:  "Phillip J. Eby" <br>
    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