[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