On Sun, Mar 20, 2011 at 4:29 PM, Jim Fulton <j...@zope.com> wrote:
> I disagree.  First, the notion that you'd import at run time is pretty odd,
> unless you count start-up in "runtime".

Right, sorry. I'm used to writing add-ons for an application. In this
environment my code isn't in charge of the startup process, but will
be called sometime in the middle of it. Some of your code might be
imported early, some very late. In this sort of unpredictable
environment, scanning comes in handy. Once some of your code is
called, you can ensure to scan and register all of it.

> Second, well, really, I'm not ready to give up on a straightforward
> definition of wiring that doesn't rely on module scanning.

Sure. I didn't mean to exclude this. Pyramid allows you to do a very
explicit configuration without any scanning. If you write an
application and have full control over all its parts, this works.

Things get complicated, once you reuse libraries which in turn have
other library dependencies with configuration actions. Ignore the
naming for the moment. You could call these application components,
arguing that a library shouldn't have any hard configuration

Currently we have an explicit approach via providing a configure.zcml
in each library, which causes all relevant parts to be imported and
hooked up. One library can include the ZCML of another library or a
subpackage of its own. Either each library provides a similar central
place, which imports all its modules with configuration actions, or
you use the scanning approach to avoid the explicit mechanism.

> Also, If there's an existing mechanism that does what I want and I'm
> just ignorant of, I'd be happy to learn about it.  If such a thing
> exists or can be cobbled together from existing ideas, I'd like to
> elevate it either as part of the ZCA or as a best-practice tool that
> stands independent of any particular application framework.

I think venusian, the venusian actions and the configuration machinery
of Pyramid come pretty close to this. Personally I think we could
extract these and roll them back into the ZTK.

Maybe there's something in Grok that comes close to this. I've just
not been able to distinguish the "Grok the web framework" code with
its convention over configuration idea from some basic explicit
configuration approach.

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

Reply via email to