Hi I would like to chime in here on the zcml I have managed to get a core stack of zope3 running on gae had to hack a lot of zope.security and zope.proxy to get it there, but it all works quite well I found I had to ignore zope.configuration to get most of the base stack working because the default configure.zcml in most packages introduced a lot of dependancies that weren't always necessary at least for me. In most cases I manually and selectively setup a whole lot of provideAdapter setups to get a minimal working set, Later I found I went back to get a minimal zope.configuration going, becuase it became way to much effort to register all of the base z3c.form components (widgets, dataconverters and terms) that I wanted registered. How is this relevant to to discussion, I found reading the unit tests didn't really enlighten me how many of the packages should be registered in the broader framework and had to rely on the zcml to work it out, however the zcml often pulled in dependancies that where not obvious from other packages because the various registrations and order of registrations that are performed in a normal zope deployment. This means the zcml is pretty important description of how the components are used in the broader context, it also means I think tests that are dependant on the zcml registration working is important, however the downside is the zcml does usually bring in things like browser views, which you may not want and so need to then gut some of the zml. Just my 2c worth T P.S. Sorry about the top posting, I though I was subscribed to the list, but wasn't so didn't have the original posting to reply to
Hey Tim, Tim Hoffman wrote:
I would like to chime in here on the zcml
[snip] Thanks for this balanced view which gives points that can be used to support both sides in the discussion: * today, the ZCML is very useful to understand how a package is supposed to be put together. Removing the ZCML will make this harder. * today, the ZCML pulls in too many dependencies that you don't really need; you want to be able to supply your own configuration for particular setups. [snip]
This means the zcml is pretty important description of how the components are used in the broader context, it also means I think tests that are dependant on the zcml registration working is important, however the downside is the zcml does usually bring in things like browser views, which you may not want and so need to then gut some of the zml.
I'll note that our dependency refactoring project will hopefully allow you to reuse more of a package's ZCML, as each package itself has a more focused goal (and no UI). It's my opinion that the dependency refactoring project is the most important we have going on right now. Whether we should be pulling out ZCML or not from these smaller packages will need a few experiments to work out the full consequences of such a procedure. Regards, Martijn
participants (2)
-
Martijn Faassen -
Tim Hoffman