[Zope-CMF] CMFBoringContent.

[Joachim Werner]

Hi!

Thanks for the feedback from Tres and Chris McD. I don't want to just
critizize the CMF. I really want to understand it better ...

> > 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.

I understand that. Though we are going a slightly different way for
Kontentor: Add list pollution is a non-issue with the "increasingly
inaccurately named" "Orderered Folder". All our internally used folders
inherit from OrderedFolder, so I can customize my add list at any time. On
the other hand, all products are available by default and can be switched
off without breaking anything (no plain text forms to fill in).

> 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.

That's indeed a very good thing. I'll have a closer look at that. Our
"puristic" solution for this is Python subclassing, which we want to make
dead easy. I can't actually say right now whether subclassing or "component
weaving" are the better concepts. Components are probably more flexible out
of the box, but subclasses are using well-known Python object class concepts
instead of add-on interfaces ...

> 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.

What we need is a system that works like the original Zope is intended to
work, i.e. "customers can have customers who have customers ...". E.g., we
have a university that has some central style guidelines, but delegates the
rest of the web presence to its faculties and institutes, which will then
delegate to departments etc. Can the current CMF implementation be adapted
to work with such a project? Currently I have the feeling that it just knows
one level of organization, e.g. one community with contributors and
reviewers.

Cheers

Joachim