Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Zope: Dev

Optional integration need not introduce dependencies

 

 

Zope dev RSS feed   Index | Next | Previous | View Threaded


jim at zope

Aug 7, 2009, 7:18 AM

Post #1 of 4 (522 views)
Permalink
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.)

--
Jim Fulton
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )


dev at projekt01

Aug 7, 2009, 7:51 AM

Post #2 of 4 (487 views)
Permalink
Re: Optional integration need not introduce dependencies [In reply to]

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
> 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 [at] zope
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 )


faassen at startifact

Aug 8, 2009, 10:26 AM

Post #3 of 4 (482 views)
Permalink
Re: Optional integration need not introduce dependencies [In reply to]

Hey Jim,

[optional integration and dependencies]

Would it be possible to turn this into a guideline document somehow that
we can include in the Zope Toolkit documentation?

Regards,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )


jim at zope

Aug 8, 2009, 11:15 AM

Post #4 of 4 (474 views)
Permalink
Re: Optional integration need not introduce dependencies [In reply to]

sure.

On Sat, Aug 8, 2009 at 1:26 PM, Martijn Faassen<faassen [at] startifact> wrote:
> Hey Jim,
>
> [optional integration and dependencies]
>
> Would it be possible to turn this into a guideline document somehow that
> we can include in the Zope Toolkit documentation?
>
> Regards,
>
> Martijn
>
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev [at] zope
> 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 )
>



--
Jim Fulton
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.