History for DomainFrameworks

??changed:
-
Domain frameworks are collections of zero or more useful object classes which deal with a particular "problem domain".  For example, the Zope PTK is a domain framework dealing with the problem domain of running a portal, and the !ZCommerce project aims to create a domain framework for e-commerce.

While it's quite feasible to develop domain frameworks as Zope products; extending, distributing, and most important, *merging and integrating* domain frameworks in Zope is tedious and problematic.  In Zope 2.2 it will at least be possible to subclass from one Product to another, which will help a lot in making site-specific extensions to a published framework without changing the base code.  But there are deeper issues to framework integration than just being able to subclass, since data management assumptions can easily creep into so many methods of a class that to change the assumptions, you must redefine every method - effectively making you write the class over again.

The !ZPatterns ideal is that domain frameworks contain no assumptions about data management and other implementation details that can/should be left to the application integrator and/or site designer.  Domain frameworks should focus squarely on the problem domain.  (Although for ease of use, it will probably be common for framework builders to include some type of "Setup Wizard" for building a set of base [Specialists] or other top-level !ZPatterns objects which their framework can then slide into.)