[Zope3-dev] Re: Moving more stuff to zope.products

[Casey Duncan]

On Thu, 05 Feb 2004 11:43:27 +0100
Philipp von Weitershausen <philipp at weitershausen.de> wrote:

> >> From a philosophical point of view, content objects are custom to
> >any > application. I have application where I never need Folder, File
> >or > weird (forbidden?) stuff like Templated Page. Thus, one could
> >argue > that all optional stuff belongs in zope.products, not in the
> >core.
> > 
> > It's a bit hard to imagine a Zope without folder.
> 
> It's hard to imagine Zope without a *container*... :) But ok, I can
> see why folders should maybe remaing a part of zope.app. The other
> stuff should move to zope.products, though.

I disagree. My notion of a folder may not be yours. zope.app should IMO
define a base container (probably not even suitable for use by itself).
A default folder for content space derived from it can be defined in a
product that is enabled by default.

I'm not just speaking hypothetically here. The fact the OFS.Folder is
part of the Zope2 core bothers the heck out of me. Granted the contract
of ObjectManager does too. Anyhow, I feel relatively assured we won't
wind up with that sort of thing in Zope3 since they are a direct result
of the mixin class model and lack in separation of concerns that pervade
Zope2.

> Btw, I also feel kind of strongly about making Templated Page and
> Python Page (and possibly Catalog!) separate from the other 'sane'
> content objects, such as File, Image, etc. *and* disable them by
> default. If people do not want to disable them by default, it should
> at least be a matter of one line in products.zcml to disable them.

I don't really see why any specific content objects need to come with
the core. 

It seems a bit silly to ship products with Zope3 that are disabled by
default. Things that are disabled probably should be separate from the
main distro.
 
> We could make two packages in zope.products:
> 
> - zope.products.basiccontent or defaultcontent
> - zope.products.codecontent

Maybe, but I don't feel too strongly about it.  I guess it will make the
products.zcml easier to manage since you can just nuke one line to
disable codecontent for example.
 
> or
> 
> - zope.products.content
> - zope.products.content.code
> 
> I prefer the first one, mainly because of the hierarchy depth and the 
> hierarchy straight-forwardness (interfaces, browser, etc.)

The nesting seems unecessary since they would be in different modules
anyway (I hope ;^). Making them different top level products seems
reasonable (and more discoverable too).

-Casey

P.S. I'm really pleased this effort is happening. This is the kind of
vigilance that is necessary to keep the codebase clean and concerns
separated. It will only be possible to keep it that way if it starts out
that way.