[Zope3-dev] zope.configuration

[Martijn Faassen]

Jim Fulton wrote:
[snip very clear explanation of how zope.configuration works]

Thanks for putting this all in one place! The bit on conflict resolution 
was helpful to my understanding - I hadn't seen it explained so clearly 
before.

> (Note that a flaw in this model is that we have no good way to undo
> actions. We don't need this for normal execution, but it would be very
> helpful for testing.)

Presumably you have thought about the registration of an equal and 
opposite action whenever we register an action that can undo the current 
registration. What are your thoughts about that? It would still need to 
work with order and I assume the component architecture has sufficient 
infrastructure to deregister registrations here.

> Actions need not be generated by executing ZCML.  They can be
> generated by processing configuration files in other formats.  They
> could even be generated by Python code.  I'm told that that's what
> Launchpad does.

It'd be nice if Steve could talk about what Launchpad does a bit more 
often...

I was talking to Philipp last night about providing an equivalent API 
that looks exactly like ZCML but is in Python. The motivation was that 
this would help in making testing easier - if you want to accomplish the 
equivalent effect of ZCML, you would write Python code that's the same. 
My idea however was that it would execute the actions immediately, which 
is different from actually generating actions as you suggest here.

Perhaps we need both, in a layered approach:


            ZCML
              |
              v
Python API for generating actions (zcpy, for zope configuration python)
              |
              v
Python API for doing what actions do now, using same names and arguments 
as ZCML (zrpy, for zope registration python)

If zrpy and zcpy essentially implement the same interface, which is 
morally equivalent to ZCML's, this might be a step in the right 
direction. On the other hand, it might turn out to be incredibly 
confusing. :)

An alternative way to accomplish immediacy in action execution is to 
have a special configuration engine which simply executes actions as 
they come in. It would have no support for conflict handling, and might 
want to just simply bail out if it runs into what would be an override 
in ZCML.

Or perhaps a testing API doesn't actually need this immediacy at all.

> I'd have no problem with generating actions in Python.  It would allow
> greater control and would probably make action generation much faster.
> If we did this, We'd probably want to improve the action-generation
> API.  We'd also need to think about how action info should be
> generated, especially wrt error reporting.
> 
> Perhaps we should support both ZCML and python action generation.

I think that this would be a useful direction to go towards, if only to 
make writing tests easier (only one API to learn instead of the 
underlying APIs that are used by ZCML).

Regards,

Martijn