On 10/6/10 08:08 , Michael Howitz wrote:
> Am 05.10.2010 um 20:21 schrieb Jan-Wijbrand Kolman:
>> Today I fixed a small bug in zc.catalog (the ftesting.zcml depended
>> on a permission name that has been removed from zope.dublincore).
> Actually the permission has been renamed (from zope.app.dublincore to
> zope.dublincore) to get rid of the "app" part in its name.
If I would be pedantic here I'd say there is no such thing as renaming a
permission. When the old name is gone, it is gone. There's no mechanism
similar to the BBB imports for the permission ids.
>> This made me realize that zc.catalog contains ZMI code in the
>> browser subpackage.
>> Are people still using this ZMI code from zc.catalog? Would it be
>> an idea to move the ZMI code out of the package (a bit similar to
>> how various zope.app.* package have been refactored)? It would
>> make maintaining this package in respect to the ZTK easier.
> zc.catalog has only test dependencies on zope.app.* packages. So you
> do not install these dependencies when using zc.calalog as a
> library. The zope.app.* dependencies might need a bit polishing. But
> I do not see a big win moving the browser part into a separate
> package. Especially as zc.catalog should depend on this new package
> for backward compatibility reasons (at least for a while).
Actually, it is more than just a test dependency. The toplevel
configure.zcml conditionally configures the browser subpackage whenever
zope.app.form is available. This zope.app.form conditional is not even
"enough", as sometimes you can still have zope.app.form on your path,
but zcml directives like addMenuItem and editForm used in
zc.catalog.browser's configure.zcml might not have been configured.
I could imagine we change zc.catalog so that the toplevel configure.zcml
never includes the browser subpackage's configure.zcml and people that
need the ZMI code, need to include the zc.catalog.browser subpackage
themselves. This would still leave the test dependency (which is
annoying but alas), but at least make the zc.catalog easier to reuse.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -