Michael Howitz wrote: > Am 15.05.2009 um 13:30 schrieb Martijn Faassen: > [...] >> Cool. It would seem to make sense that the named template mechanism is >> bundled along with the page template library anyway (instead of the >> form >> library). zope.formlib currently depends on zope.app.pagetemplate >> too so >> we could easily leave a backwards compatibility import in place. > > > Done. Moved namedtemplate to zope.app.pagetemplate and made new > releases of > zope.app.pagetemplate > zope.formlib > > Also cut the dependency of zope.app.publication on zope.app.exception > by moving ISystemErrorView to zope.browser. Released: > zope.browser > zope.app.exception > zope.app.publication
Very cool, thanks very much for doing this work! Looking at the new dependency cycle graphs again. This is the before: http://startifact.com/depgraphs/zope_app_publisher_cycles.svg And this is the after: http://startifact.com/depgraphs/zope_app_publisher_cycles2.svg zope.app.exception is now taken from the graph (good!) Somehow a direct cyclical dependency between zope.app.publication and zope.app.publication now exists where there wasn't any before. zope.app.publication now depends on zope.app.publisher and it didn't do so in the past. Ah, it looks like this was actually a missing dependency which got added about 6 weeks ago. We need to get rid of it... Let's continue with the other refactoring: It looks like we still need to lose the dependency of zope.app.publisher on zope.app.component, or alternatively (or in addition) lose the dependency on zope.app.component on zope.formlib and zope.app.security. The zope.app.security dependency turns out to be only a test dependency, so I just made it such. zope.app.component is starting to look pretty empty. I can see three things still going on in it: * some browser views in zope.app.component.browser. These are to support the ZMI and can stay where they are. * the registration of the zope:view and zope:resource directives. I'm not sure what these are for, as we have browser:view and browser:resource. Perhaps these can be safely lifted into zope.app.publisher, which defines the browser:* varieties * the code in zope.app.component vocabularies. This is support code to create vocabularies for utilities. It depends on zope.interface, zope.component and zope.schema, and zope.app.interface. It might be sensible to move this vocabulary stuff (along with the one in zope.app.interface that we depend on) into a package called zope.componentvocabulary. We can jettison zope.app.component then. zope.componentvocabulary would depend on zope.schema, zope.component, zope.interface and zope.security only. We can then make zope.app.publisher depend on zope.componentvocabulary and lose the zope.formlib dependency, along with the zope.app.security dependency. Anyone wants to work on zope.componentvocabulary? It'd contain zope.app.component.vocabulary + surrounding tests, and zope.app.interface's vocabulary that it depends on. Regards, Martijn _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )