[Zope3-dev] Re: yagni on overrides?

[Martijn Faassen]

Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Martijn Faassen wrote:
>> Tres Seaver wrote:
>> [snip]
>>> One example of such an implementation would be an optional, lxml-based
>>> directive which uses the native structure of the ZCML file and XPath.
>>> E.g. to include only adapters from a package ::
>>>
>>>   <select package="my.package" file="configure.zcml">
>>>    <path>//adapter//path>
>>>   </select>
>>>
>>> The XPath processor would need to be passed the current namespace
>>> mapping here, if we want to select items from the non-default namespace.
>>> Otherwise, this would function pretty much like the 'include' directive
>>> (it might even use that diretive's handler under the hood).
>>>
>>> With an egg-based story, we can more easily use stuff which depends on a
>>> third-party library like lxml;  folks who can't install lxml just lose
>>> this feature.
>> In general, I don't like relying on the syntactic structure of ZCML 
>> files for this. I'd prefer to have a semantic of configuration actions 
>> and a way to disable them.
>>
>> If this can be a quick fix that helps people, so be it, but I think a 
>> way to manipulate configuration actions from Python code is a better 
>> overall approach.
> 
> I disagree, as I've said before:  I don't want policy in software.  This
> may be de gustibus at this point.

Not every debate has to do with whether policy is in software or not. As 
far I can tell, this debate is not one. :)

I'm merely proposing not to rely on the syntactic structure of ZCML for 
doing this. I don't want policy to rely on the syntactic structure of 
the XML. Instead, I propose a python API to manipulate the actions as 
generated by ZCML. We can then build ZCML directives that use this API. 
Policy remains wherever you want it.

I think this is part of a larger project to create a better Python API 
for actions. Currently ZCML handles rather a lot of action construction 
that would be nicer if it were abstracted on a slightly higher level of 
abstraction with a good Python API. This would hopefully allow alternate 
configuration mechanisms (such as Grok) to share more code with Zope 3.

Regards,

Martijn