[Zope] [ZGotW] Issue #7 (Closed)

21 Mar 2000

      The current issue of "Zope Guru of the Week" has closed:

===================================================================
Issue #7 -- To ZClass or not to ZClass?
===================================================================

       Status:  Closed 

    Zen Level:  Chela (4/8)

     Keywords:  ZClasses 

 Submitted by:  Tres Seaver tseaver@palladion.com
-------------------------------------------------------------------
 When building a Product using ZClasses, I often want to create
 a "root" ZClass, which the manager will create in a normal
 folder, and which will then expose the Product's other ZClasses
 in its Add list.  The DTML methods for the root are thus defined
 within this root ZClass.

 The Product ends up looking like::

   Control Panel
    +- FooProduct
       + FooItem_add_permission
       +-FooRoot
         +- FooItem
         +- FooItem_add
         +- FooItem_addForm
         +- FooItem_factory
         ....
         +- index_html
         +- some_root_method_dtml
       + FooRoot_add
       + FooRoot_addForm
       + FooRoot_Factory
       + FooRoot_add_permission

 * What are the drawbacks to this approach? 

 * Suggest alternatives.
-------------------------------------------------------------------

  Reviewed by:  Tres Seaver tseaver@palladion.com
-------------------------------------------------------------------
 Hmmm, I don't seem to be doing so well on picking topics.  Here
 is what I had in mind:

  * This site is an instance of the 
    "ZGotW product":http://www.zope.org/Members/tseaver/ZGotW,
    which has a "main" factory, ZGotWRoot_factory, in its root
    folder.

  * This factory does *not* create an instance of a "folderish"
    ZClass, but rather, creates a normal Folder and populates
    it from a set of default DTML objects, along with a ZCatalog.

  * Individual issues of ZGotW are created within this folder
    as instances of the ZClass, ZGotWIssue, using the code in
    those "cloned" DTML objects.

 My rationale for adopting this approach, rather than creating
 a "folderish" ZClass, was to allow each instance of the "root"
 to be independently customized;  the "common" behavior of a
 ZGotW site is included in a set of utility methods, which can
 be tweaked to enforce different policies, or change the
 look-and-feel of a particular site.

 The downside to this choice is duplication of code:  should I
 find a bug in the original, default code, I have to then fix it
 in each instance as well as the Product.

 Comments, anyone?
-------------------------------------------------------------------