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

[Casey Duncan]

On Wed, 04 Feb 2004 18:12:06 +0100
Philipp von Weitershausen <philipp at weitershausen.de> wrote:

> Hi there,
> 
> in the currently ongoing process of reorganizing Zope3's package 
> structure and gutting out zope.app, I think the main packages that
> have yet to be moved are:
> 
> - zope.app.workflow
> - zope.app.content
> - browser skins
> 
> While the first is probably easy to agree on, I realize that the
> latter could be a point of discussion.
> 
> Anthony Baxter argued that just moving zope.app.content to 
> zope.products.content will not flatten the product hierarchy at all. 
> That is certainly true since the depth of the package remains the
> same, however the package hierarchy will be straightened out a lot.
> Remember how all interfaces are in zope.app.interfaces.content, all
> browsers views are in zope.app.browser.content...? (see discussion
> several months ago...)
>  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.

+++1
 
> The same essential argument applies to the browser skins. Here, it
> makes even more sense, because a browser skin is usually the first
> thing a developer will customize in his/her own application anyway. By
> marking them as optional by moving them zope.products, we encourage
> people to actually do so. Otherwise we'll end up with the Plone
> dilemma, in which every Plone site looks like plone.org, at least very
> similar.

ditto.
 
In general I think anything that describes policy that will be
overridden with any frequency (like 1 or more times ;^) should not be in
the core. Some others I think we might consider moving:

onlinehelp
rdb
schemagen (is this even still used?)
security? (not sure but it seems policyish)
services (not the whole thing, but this seems like a big grab-bag)

Another partially related thought:

Why don't the __init__.py files have a (terse) docstring that explains
the purpose of the package? Some of their names are so general, that
their purpose is not readily apparent. Even something like """The splat
package facilitates the canonical splat protocol from rfc1234""" would
be very helpful.

-Casey