[Zope3-dev] Re: yagni on overrides?
Martijn Faassen
faassen at startifact.com
Fri Apr 27 13:52:02 EDT 2007
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
More information about the Zope3-dev
mailing list