Advertising

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.