[Framework-Team] Namespace organisation

Martin Aspeli optilude at gmx.net
Sun Apr 30 20:17:25 UTC 2006

Hi guys,

At the Archipelago sprint one issue came up that warrants some discussion.  
How do we organise the CMFPlone and plone namespaces?

For example, Products.CMFPlone.browser.interfaces is very large and  
contains a mixture of view interfaces for portlets, more general views and  
some of the navtree stuff. Some of the implementation is broken down into  
sub-packages of CMFPlone.browser. A lot of that is adapters, although Jeff  
Roche made the adapters in ATContentTypes all live in a top-level  
'adapter' package. Meanwhile, we're planning to move more things into a  
top-level plone package, e.g. plone.schema and plone.portlet. Some of that  
will be general, some of it may be general interfaces with an  
Archetypes-based implementation. Oh, and Cubed lives in a single-level  
plone' package in the plone svn repo, which may cause us some  
organisational headaches when we want to use that package name for more  
general things that are dependencies of Plone 3.0...

I think we need a story and document it in the Developer Reference.

My personal thoughts are:

  - Putting adapters in an 'adapter' sub-package is silly. A lot of stuff  
in Zope 3 is an adapter, and when interfaces and adapters and the things  
they work on live in separate parts of the package, they can be difficult  
to find. However, for small, localised packages, it may make sense to use  
that naming.

  - CMFPlone.browser will grow. Plone is mostly a UI-layer, right. :-) We  
need to organise it carefully. I think the current top-level 'interfaces'  
approach is not very good - different logical units should live in  
different sub-packages of CMFPlone.browser, with their own configure.zcml  
if it makes sense. Generic views live in the top-level CMFPlone.browser.

  - Infrastructural components should be moved to a top-level plone  
namespace. I see CMFPlone as the package that pulls them all together and  
presents them in a unified UI. Examples from the sprint will probably  
include plone.schema, plone.portlets and plone.ajax.

... but those are just brainstorming. I'm sure the rest of you have a lot  
of ideas too. :)


"You can just adapt yourself out of it..." // Archipelago sprint 26/04/2006

More information about the Framework-Team mailing list