[ZDP] BackTalk to Document The Zope Book (2.6 Edition)/Extending Zope

[webmaster at zope.org]

A comment to the paragraph below was recently added via http://zope.org/Documentation/Books/ZopeBook/2_6Edition/CustomZopeObjects.stx#2-35

---------------

    ZClasses are tools that help you build new types of objects in
    Zope by defining a *class*.  A class is like a blueprint for
    objects.  When defining a class, you are defining what an object
    will be like when it is created.  A class can define methods,
    properties, and other attributes.

      % Anonymous User - Nov. 17, 2002 5:15 am:
       The following question springs to mind at this point: How does one decide (particularly the newbie) whether
       to use a Zope ('internal') Product, a python-based ('external') Product or ZClasses for e.g. a new
       project/application?
       Each *must* have its relative merits, but which, where?

      % Anonymous User - Apr. 29, 2004 10:57 am:
       According to the ZopeWiki, you should NEVER use ZClasses. http://www.zopewiki.org/ZopeDosAndDonts

      % Anonymous User - Sep. 25, 2004 1:10 pm:
       Why do I learn about ZClasses if I am not supposed to use them? (I checked zopewiki, it really says you
       aren't supposed to!)

      % Anonymous User - Sep. 25, 2004 1:11 pm:
       Why do I learn about ZClasses if I am not supposed to use them? (I checked zopewiki, it really says you
       aren't supposed to!)

      % Anonymous User - Oct. 20, 2004 3:46 am:
       Posted by Dieter Maurer on zope at zope.org: 
       There are strong differences in the opinion about "ZClasses".

       There are still and have been (in the past) some problems
       with ZClasses. Due to these problems, some people think,
       ZClasses should not be used. I do not share this opinion.

       The problem that is still there: you must not inherit
       from a ZClass defined in a different product. While
       it apparently work in the first place, it will break as soon
       as you export your product (the link between deriving and
       base class is lost). That is nasty, if you are unaware.

       There are thousands of unit tests for Zope. These unit
       tests ensure, that the likelyhood it high, that Zope still
       works in new releases. However, there are almost no unit
       tests for ZClasses. As a result, ZClasses broke often
       between releases. Usually, it was only a minor issue --
       but maybe, too large that you could fix it yourself.

       These are the (known) risks.

       I used to use ZClasses for large projects -- and did not make
       bad experiences. It is very easy to integrate standard Zope
       objects in your own ZClasses to create new applications.
       I even created abstract ZClasses and mixin classes. All worked very well.

       Nowadays, I no longer use ZClasses. We moved over to the CMF and
       Archetypes. They provide similar bundling features as ZClasses,
       are much more efficient (with respect to runtime) and
       the code is maintained in the file system and thereby subject
       to standard revision processes. The latter is essential
       for really large projects.
       You must learn a lot when you want to follow this route --
       much more than when you use ZClasses.

       To summarize: when you are still learning or you make smaller
       prototypes, you can use ZClasses.
       For long living projects or (runtime) resource critical applications,
       file system based code is superior. It is faster and can be
       revision/source controlled.