History for Racks

??changed:
-
A key difference between a "site" and an "application" is that applications create, delete, and otherwise view/manipulate dynamic data.  Whether this data is stored in a persistent ZODB object, LDAP, SQL, or the filesystem, managing objects with some type of unique identifier is a common application theme.

Typically, however, developers will simply code these object manipulations directly as calls to methods of the appropriate type.  Aside from being tedious and repetitive, however, this practice also violates the principle of InformationHiding, thus hampering !FrameworkReusability.

The solution?  Delegate data management to a Rack.  Racks provide as their primary interface these methods:

 * 'getItem(key)' - retrieve an object

 * 'newItem(key)' - create a new object of the appropriate kind

(Notice that there is no delItem - you must ask an object to delete itself.)

The Rack itself implements the storage details.  Racks are DataManagers, which means they can also provide arbitrary additional data and behavior to their contents, which must be RackMountables.

Currently, the ZPatterns implementation provides a basic Rack that uses the ZODB for storage, but can be easily subclassed to use other storage techniques such as SQL, LDAP and so on, by overriding just a few methods.  For example, the LoginManager system derives the classes for UserSources from Rack, making LDAP and SQL UserSources possible.  There are several benefits:

 * Generic Racks can be developed for a variety of storage backends, which are then reusable for any number of applications

 * Application-level code doesn't know or care *how* their data is stored, making it easy to change backends at a later date.

 * The Rack interface becomes a common idiom (or "standard idiot" as !JimFulton would say), giving an application designer/developer one less thing to think about.

 * The application developer/integrator can now be someone who doesn't know how to access a database, or even how !SQLMethods work, as long as someone knowledgeable configures the Rack.

As useful as Racks are by themselves, they are even more powerful in the context of a Specialist.  [Specialists] provide another layer of abstraction above Racks that adds capabilities such as traversability (i.e. URL-based access to contents), "class methods", and the ability to present a unified interface to data which is actually stored in multiple Racks.