[Framework-Team] Re: Namespace organisation

Rocky Burt rocky at serverzen.com
Sun Apr 30 20:54:51 UTC 2006


Just some quick notes.  I agree on using the toplevel plone.* package
for all the plone stuff.  In my opinion, we should try following the
zope.* naming conventions for where we place stuff.  Of course this
won't capture of all of the plone use cases, but it should capture at
least a few.

Also, remember that zope3 is moving away from packages named as api or
zapi or whatever so we should avoid those as well.

Private packages should be named with a leading underscore to indicate
people writing third-party plone products shouldn't use those packages.

Interfaces should be in a interfaces module or package based in the
2nd-level package namespace (ie plone.schema.interfaces,
plone.portlet.interfaces).  The same with testing package/modules.

And since Plone 3.0 is going to require at least zope 2.10 and cmf2,
being able to use Product-less products will work fine, so it will work
out no problem to use plone.* as the toplevel package (otherwise
Products.plone.* would have to be the toplevel package).

- Rocky

On Sun, 2006-30-04 at 21:17 +0100, Martin Aspeli wrote:
> 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. :)
> 
> Martin
> 
-- 
Rocky Burt
ServerZen Software -- http://www.serverzen.com
News About The Server -- http://www.serverzen.net





More information about the Framework-Team mailing list