[Zope-dev] Optional integration need not introduce dependencies
Roger Ineichen
dev at projekt01.ch
Fri Aug 7 10:51:10 EDT 2009
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 at 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 )
>
More information about the Zope-Dev
mailing list