I’m new here.. almost certainly these comments are off-base… then again, sometimes an idea “from outside” can be helpful. So here’s a crazy thought before I go to bed….
I wonder if the configuration done by zcml might not be better if it resided inside a ZODB, and was manipulable at runtime, and more importantly separate from the source code.
It couldn’t be the normal “instance” zodb, but rather sort of like a “classinfo” zodb that took care of all the linkage info. Of course, the system would have to be made a bit more robust so it stays up when modules w/ syntax errors are loaded, for example.
The biggest reason: I can imagine that when deploying a package, various configurations, for instance security, but also adding internationalization, have to be adapted for the specific site. This way, they could be deployed without access/change to the source tree (after it has been “plunked down” in the python path), and further customization could be done, if necessary, remotely. Also, sites that “have to stay up” could be reconfigurable on the fly (though one would have to be careful about disabling the core system!).
Also, those pythonistas who object to zcml not being in python will have less to see when they complain. This at least drives home the point that this config isn’t logically part of the code. :)
Zcml would stick around as an import/export/diagnostic/backup tool.
_______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com