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

[Jim Fulton]

Casey Duncan wrote:
> 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.

Right, the default will be Folder. You will be able to override this
with something else.  90% of Zope users will not care to do so, however,
and certainly won't want to have to.

> I'm not just speaking hypothetically here. The fact the OFS.Folder is
> part of the Zope2 core bothers the heck out of me.

Sorry to hear that. :)

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

I don't understand what that has to do with it.  Most people aren't
going to totally refedine Zope at every level. They will want some standard
batteries to be included.

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

To make it usable.

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

What ships with Zope 3 is an open issue that we aren't really thinking
about yet.  Some of the things in zope.products will be shipped in
common distributions, and some won't be.

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

yagni :)

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

Yup

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

Yes

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org