Tres Seaver wrote:
Hash: SHA1

Martijn Faassen wrote:
Tres Seaver wrote:
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
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.



Zope3-dev mailing list

Reply via email to