On Oct 17, 2007, at 4:44 PM, Wichert Akkerman wrote:

A common issue we are seeing is that we have eggs depending on each
other, but they still need to load the zcml from those dependencies
somehow. As a temporary solution to play with the concept I added
something simple to the plone.recipe.zope2instance buildout recipe.

It allows you to define entrypoints like this:

          "zope.zcml" : [
              "meta = plone.session",
              "configure = plone.session",

this tells the system to load meta.zcml and configure.zcml from plone.session.

Sure, where presumably you could list multiple files.

Or maybe:

  entry_points = """
  meta = <include package="plone.session" />
  configure = <include package="plone.session" />



(This example uses the ConfigParser syntax for specifying entry points, which I prefer.)

This suggestion gives you the flexibility to specify ZCML to be included by package name, by file name, or both.
It lets you specify other ZCML as well.

          "zope.zcml" : [
              "meta = plone.session",
              "configure = plone.session",

I am not quite sure what the best way to hook this into Zope itself is. For Zope 2 we can do it in Five, since that is where all the zcml loading
logic currently is. Or we could move that into Zope2 itself somewhere.
I'm not familiar enough with Zope3 to know what the best place would be there.

I recommend creating new configuration directives that do this.

  <include meta_entry_points />
  <include entry_points />

These directives might also accept an projects attribute to name specific eggs, by project name, to load from.

This could be used in Zope 2 and in Zope 3 apps that want it. (Mine wouldn't. :)

Doing it this way keeps it simple to use while providing some added flexibility to do explicit configuration before or after this automatic configuration.

One problem is ordering: the zope.component zcml needs to be loaded first.

As Tres noted, a package that needs zope.component to be included should include it. In general, I recommend that a package include all of the ZCML it expects to be included.

I understand that some folks would fine something like this to be very useful. I can especially see the benefit for pluggable apps, like Plone and Zope 2.. I support this idea. I would almost certainly not use it myself and can't justify my time to implement this. I think the implementation is pretty straightforward though and encourage folks who want this to implement it. It can be implemented as a separate package, although I wouldn't object to eventually incorporating it into zope.configuration.


Jim Fulton
Zope Corporation

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to