Re: [Zope3-dev] zcml in config db?

2006-02-14 Thread Lennart Regebro
On 2/14/06, Shaun Cutts [EMAIL PROTECTED] wrote:
 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!).

1. You still want to have that in some source tree, so that you can
change it, check it in to svn and run diffs on it.
2. Changing basic configuration through the web can be a security problem.

That said, some configuring should definitely be stored in the ZODB
and configured through the web, and where to put that border is not
always obvious.

 Also, those pythonistas who object to zcml not being in python will have
 less to see when they complain.

No, because not only is the configuration now not in Python, it's not
even in a text format, but in the ZODB. They are gonna *hate* that. :)


 This at least drives home the point that
 this config isn't logically part of the code. :)

Most of the ZCML config is largely part of the code...

--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] zcml in config db?

2006-02-13 Thread Shaun Cutts








Hello,



Im new here.. almost certainly these comments are off-base then
again, sometimes an idea from outside can be helpful. So heres
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 couldnt 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 isnt logically part of the code. :)



Zcml would stick
around as an import/export/diagnostic/backup tool.



- Shaun






___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com