Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Martijn Faassen wrote:
Tres Seaver wrote:
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.
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">
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
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
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.
Zope3-dev mailing list