Hi Jim
Betreff: [Zope-dev] Optional integration need not introduce
dependencies
In discussing dependencies, as we try to clean up
dependencies of Zope (especially ZTK) projects, I've noticed
a pattern that I think deserves some special handling.
Often, a module (including a ZCML file) within a project
provides an implementation of an interface defined by an
external package or an adapter of a class or interface
defined in the external package. If the module is optional
and exists solely to integrate with the external API, then
the external project need not be a dependency. Why?
Because an application won't use this module unless it
already uses the external project.
For example, lots of projects provide publisher views or zcml
configuration directives. As long as these are in optional
modules or ZCML files, then dependencies on zope.publisher or
zope.configuration aren't necessary, as no one will use these
modules or zcml files unless they're already using
zope.publisher or zope.configuration.
Again, this assumes that these modules are optional. For
example, if a project's configuration file, configure.zcml
registers views or includes a configuration file that
registers views, then the dependency on zope.publisher is not
optional.
Let's look at a more specific example. zope.app.publisher
provides some xmlrpc view registrations for zope.container in
xmlrpc/configure.zcml. If the xmlrpc module was optional, or
if these container registrations were conditedl [1]_ on
zope.container having been installed, then zope.app.publisher
wouldn't need to depend on zope.container [2]_. As it stands
though, one can't include the main configuration for
zope.app.publisher without also configuring the container
xmlrpc views, so zope.container is required.
Jim
.. [1] We can make these registrations conditional on
zope.container like this:
configure condition=installed zope.container
view
for=zope.container.interfaces.IItemContainer
type=zope.publisher.interfaces.xmlrpc.IXMLRPCRequest
provides=zope.publisher.interfaces.xmlrpc.IXMLRPCPublisher
factory=zope.container.traversal.ItemTraverser
permission=zope.Public
/
view
for=zope.container.interfaces.IReadContainer
type=zope.publisher.interfaces.xmlrpc.IXMLRPCRequest
provides=zope.publisher.interfaces.xmlrpc.IXMLRPCPublisher
factory=zope.container.traversal.ContainerTraverser
permission=zope.Public
/
/configure
.. [2] This assumes we could get rid of the zope.container import in
browser/tests/test_directoryresource, which I strongly suspect
we can.)
I think XML-RPC just belongs to an own package e.g. zope.xmlrpc. It doesn't
make sense to have XML-RPC in a package other then an own. If we move the
XML-RPC part out of other packages, then we have the question should the
zope.xmlrpc package depend on IContainer? Probably not and the new
zope.xmlrpc
package should use your suggested conditional configuration.
Such an own zope.xmlrpc package whould depend on the publisher as much as
the XML-RPC implementation does. This allows to use a custom XML-RPC
implementation based on something else then the publisher concept.
(custom xmlrpc package)
Does this make sense?
btw,
I think XML-RPC should be an optional package like z3c.jsonrpc.
The same belongs to FTP and WebDav support.
(Not sure if WebDav is optional, at least FTP is optional configurable
at zope.conf level)
Regards
Roger Ineichen
--
Jim Fulton
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! ** (Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
