On Wednesday 03 September 2008, Martijn Faassen wrote:
One observation is that the pattern of '.browser' subpackages tends to expand the dependency structure significantly. Often you want to use non-browser functionality and don't care about the UI that ships with .browser. At the same time .browser tends to add dependencies to the overall package.
Other times (such as for zope.app.form.browser) the main reusable functionality of a package is actually almost completely in the .browser sub package. It might be nicer to flatten the namespace then and move things from .browser into the main package.
It might therefore make sense to review packages one by one, and see whether zope.foo.browser can be factored out into a zope.fooui package or something like that. Of course the question remains how we can get from A to B without a major breakage in backwards compatibility then.
Jim must have read your message with a big smile on his face. He was arguing for this approach of flat package names about 2-3 years ago and I shot that proposal down. I hate when I only realize design mistakes years after Jim does. ;-\ For several packages we took the following approach. Most packages that have browser packages are in zope.app; for example, zope.app.folder (we did not convert this package yet). We then took the API and moved it to zope.folder. We imported the API in zope.app.folder again to maintain BBB. This way zope.folder has the minimal deps and zope.app.folder contains the browser code. BTW, zope.app.form is a big exception. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"