Stephan Richter wrote:
On Monday 25 April 2005 10:52, Roger Ineichen wrote:(Use case extension: There is a third package 'c' or even more (that the usecase of frameworks).)
The alphabtice order of configure.zcml like Stephan proposed
is one solution. But I like a more explicit solution for this
like Dominik proposed with a additional application level
for 3rd party packages.
I did not propose to have alphabetical order. I said to write in a-configure.zcml:
<configure> <include file="b-configure.zcml" /> <include package="apps/a" /> </configure>
This used to work.
Yes, I'm fully aware that your example works, but the solution is also a 'hack', because it simulates
the application/framework-level inside a-configure.zcml. Therefore all the time when a new package is added
that is depending on the framework 'a' we have to modifiy a-configure.zcml. So if we like to use any automated
deployment tools such as zpkg we can not only move package-includes from a skel folder to the live-package-includes,
but also we have modify them accordingly.
This is the only thing I really do not like about the proposed solution.
I really do not want to add yet another layer, because it will never end.I'm going with you that we should add additional layers deliberately, but the bigger evil than a new, abstraction layer is to
simulate such a level within the deeper ones.
This layer is justifiable at the moment because the zope application already uses such a layer itself
(direct include of zope.app within the site.zcml).
_______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com