History for Specialists

??changed:
-
Like Zope itself, specialists are hard to describe in a single sentence, if you want to say more than "they're really cool".  Specialists can be thought of as "service objects" which provide methods for creating, searching for, and otherwise accessing objects related to a particular application service.  For example, a phone directory Specialist might provide methods (user interface as well as implementation) for adding entries and searching the directory, and even methods for other parts of the application to integrate phone directory lookups.  Here are some other ways to think about Specialists:

* Functionally, they provide a single access point for all application services relating to an abstract category of objects.

* From a design patterns perspective, the specialist pattern is a hybrid of such concepts as AbstractFactory, ObjectTrader, Data Manager, and Class As Object.

* From an application-building perspective, a Zope application can be built as a set of one or more (possibly nested) Specialists, optionally communicating with one another and/or referenced by a thin layer of application-level methods "above" them.  (Thus creating many opportunities for reuse across time, projects, and components.)

* From a framework builder's perspective, Specialists provide a "universal hookpoint" for framework users to extend, customize, and combine components from both domain-model and implementation-level frameworks.

* From an analysis and design perspective, Specialists help the designer stay focused on "Roles Before Objects" (see http://g.oswego.edu/dl/rp/roles.html)

For an example of how Specialists provide building blocks for collaboration between framework classes, see the DropZoneExample.

Shane Hathaway posted a nice explanation of Racks and Specialists to the zope-dev mailing list: RacksAndSpecialistsSimplified.