[Zope-CMF] CMFBoringContent.

[Tres Seaver]

Joachim Werner wrote:

>>Comments are appretiated :)
>>
> 
> Hi!
> 
> I am known to be very critical about the CMF. And Erik's excellent how-to
> gives me the opportunity to point at some weaknesses I see in the CMF
> architecture:
> 
> Let's compare the procedure you describe in the how-to with the procedure of
> adding a non-CMF content type. The result:
> 
> "Normal" Content Type:
> 
> - Create a folder in "lib/python/Products" and enter the folder
> - Create an "__init__.py" with some rather easy-to-learn registration
> information
> - Create a "productname.py" file with all the stuff needed to describe the
> content type
> - create a www folder with all the icons and a dtml folder with all the
> default DTML
> - restart Zope

> 
> CMF Content Type:
> 
> - do all of the above, only that the dtml folder is called "skins" and that
> you have to use some new, specific syntax to comply with the CMF framework
> 
> Now the additional work starts:
> - register to portal_types
> - check registration to workflow and change if necessary
> - register portal_skins

 >

> All the additional work is not automated though all the necessary
> information would be available. Also, most of the actions are error-prone
> and some of them could break the CMF if not done properly. E.g., I can write
> any icon name in the portal_type registration, regardless whether the icon
> exists or not. Many things are just bound by name and can be overloaded by
> accident. Why not add new content types automatically when they are
> installed, or if that is not desired, make them an option that can be
> activated/deactivated in the portal_types tool?
> 
> So compared to the plain old Zope, I don't get more comfort and ease of use,
> but more things do learn and do wrong. All of this in exchange to some
> rather basic functionality like basic workflow support or a slightly more
> intelligent catalog.
> 
> I know that's a rather biased opinion, but I am still waiting for somebody
> to explain me what the CMF can really do to make content management
> application development easier instead of just "less flexible" ...


Note the distinction here: CMF content types are not, *by design*,
automagically added to CMFSite instances, even though their products
are available; this choice answers the frequent complaint about
Zope's "add list pollution." Qell-behaved CMF Products also provide
a script to be used as an ExternalMethod for doing the "standard"
installation steps you note for a specific CMFSite instance.

Note as well that the manager of the site may chose to install the
content type under a different ID than the default indicated in the
product, or even to install it more than once, and to associate different
workflow, skin methods, metadata policies, etc. with the different
types. The CMF tries hard to put this kind of control in the hands
of the site manager, rather than the programmer.  The indirection

of "types" over "classes" is an important part of this strategy.

This strategy, which moves complexity out of monolithic classes on
the filesystem and into configuations of collaborating instances in
the ZODB, is an important element in the new "component architecture",
   http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture
we are developing.  The "separation of concerns" which such a strategy
enables makes developing and maintaining any single class easier,
as each class has less to do;  the tradeoff is that one must implement
more classes.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com