[Zope3-dev] zope.configuration

Jim Fulton jim at zope.com
Fri Mar 17 06:34:57 EST 2006


Martijn Faassen wrote:
> Jim Fulton wrote:
...
>> (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?

I haven't though that much about it.  I just mention it as something
we'll probably want to come to terms with if we expect people to
start writing actions more directly.

I would just give actions both forward and reverse callables and
arguments.

 > It would still need to
> work with order

The idea is that after applying configuration, you'd keep the
resolved sequence of actions around so that you could call their undo
methods later.

 > and I assume the component architecture has sufficient
> infrastructure to deregister registrations here.

It does now.

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

I'll note that we typically write 3 kinds of tests:

1, Unit tests.  For these we go out of our way to avoid
    configuration.  We make agressive use of skaffolding, if
    necessary, to avoid dependence on other systems.

2, Component functional tests.  These are tests of a package
    using the default configuration use by the package.  This
    allows us to test things like configuration and UI without
    depending on a particular application.  This was the primary
    motivation for layers in the new test runner.

3. System tests, in which we test a very specific configured
    application.

For 1, we don't need configuration support.  For 2 and 3 it's
important to use exactly the ZCML provided by the package or
by the application respectively.  Fly what you test, and test what
you fly.  If you use ZCML for configurating, use it for functional
and system tests.

...

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

I strongly oppose and discourage using a separate API for tests, for
the reasons given above.

The main reasons, IMO, for providing a Python API are:

- Provide greater control for those who want it.
   For example, to allow more abstract configuration tools,
   avoid "repetition", etc.

- Provide an alternative for people who just can't stand pointy
   brackets. (Who can blame them? ;)

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


More information about the Zope3-dev mailing list