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:

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 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).


Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to