[Zope3-dev] zope.configuration

Martijn Faassen faassen at infrae.com
Fri Mar 17 13:13:24 EST 2006


Jim Fulton wrote:
> Martijn Faassen wrote:
> 
>> Jim Fulton wrote:
>>
>>> Martijn Faassen wrote:
>>>
>>>> Jim Fulton wrote:

>> [snip]
>>
>>> 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.
>>
>> Yes, that's what I was thinking of too. Good. :)
> 
> I'll note that this is a half baked idea and may not work.
> In particular, as successful "undo" would need to restore
> configuration that the action overrode.  I'm not sure that
> the benefit is worth the bother of getting this right.

That's true, I hadn't considered that.

[skaffolding in unit tests]
>> For 1. we don't need configuration support, but what I think could be 
>> improved is the skaffolding. Often in unit tests we do register 
>> something with the component architecture.
>  
> This can be avoided more often than you realize.  

It's a good thing you know what I realize. :) Anyway, I've seen lots of 
testing code that does not avoid this. The people who wrote this test 
might have done it unnecessarily, but that points to doing it the right 
way apparently being harder than doing it the wrong way. Are you saying 
this is an education/documentation issue?

> Also, there
> are simple APIs that make this straightforward when it is necessary.

I know. I'm looking for ways to make it even simpler, as I've seen 
people actually
run into this issue.

>> Right now we need to know two systems whenever we write code that 
>> needs unit tests:
>>
>> * ZCML for when the code needs to actually run
>>
>> * component architecture APIs when we need to set up some stuff to 
>> support our tests.
>>
>> What I'm suggesting is having a Python API that looks much like ZCML 
>> but does the component architecture registration bit of what ZCML 
>> does. Less things to learn for the person writing (or reading) the 
>> scaffolding for the tests.
> 
> 
> OK,  I think we'll be better served by different APIs. An API necessary
> to create actions will, I think, be too combersome for simple registration
> needed by tests.

Yes, two APIs, same interface. One creates actions, the other one 
doesn't. The one creating the actions could hopefully be implemented in 
terms of the other.

>> Since we also were talking about a Python API to generate ZCML 
>> actions, it seems to make sense that the same API could also have an 
>> implementation that *does* generate actions.
> 
> ZCML actions require information that isn't necessary when just registering
> components for tests.
> 
> I won't argue.  If we create an API for configuration, and you want to
> use it for setting up tests, be my guest.  I'll stick to the simpler APIs
> myself.

Sounds good.

> I'll note, however, that I think there will be lots of interesting
> small Python applications that don't use zope.configuration.
> zope.configuration is helpful for providing flexible configuration
> of an application server. I think and hope that there will be lots
> of interesting applications that don't use an application server
> and that do use Zope components.  These components should not depend
> on zope.configuration and their unit tests should not introduce such
> a dependency or be made more complex just to provide some sort of
> consistency.

That's a good point. Perhaps the API I'm talking about belongs in 
zope.component (and anything else that ZCML statements exist for, in the 
end). It's likely a very thin layer over what's already there. Then 
zope.configuration can take the interfaces and implement an action-based 
and ZCML based system for them.

Anyway, it's just an idea. Maybe I'll find some time to look into this 
eventually. I know enough of the innards of zope.configuration by now to 
also be potentially helpful in trying to pull it apart into a Python API 
(the action-generating one) and the ZCML bit.

Regards,

Martijn


More information about the Zope3-dev mailing list