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
(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
It'd be nice if Steve could talk about what Launchpad does a bit more
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:
Python API for generating actions (zcpy, for zope configuration python)
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
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
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).
Zope3-dev mailing list