Re: [Zope-dev] zope.app.publication dependencies (volunteers needed!)
Hey, Chris McDonough wrote: [snip] I tried to go after this today (reversing the dependency setup between zope.formlib and zope.app.form). There are hundreds of changes that need to be made to move interfaces to zope.formlib. I made them (more or less mechanically) but then couldn't get the tests to pass. Since I don't actually use zope.formlib, I don't think it's appropriate that I commit anything. All right, thanks for trying. Hopefully someone else can take a look at it at some point. OTOH, I'm pretty convinced that this action would be a win for packages that depend on formlib. I found these: ./zope.app.component-3.7.0-py2.5.egg/EGG-INFO/requires.txt:zope.formlib ./zope.app.exception-3.5.0-py2.5.egg/EGG-INFO/requires.txt:zope.formlib ./zope.app.zcmlfiles-3.5.3-py2.5.egg/EGG-INFO/requires.txt:zope.formlib With the recent changes zope.app.component is almost devoid of code and packages that relied on zope.app.component now can rely on other packages and entirely avoid the zope.formlib dependency. zope.app.exception only depended on formlib's namedtemplate facility which now resides in zope.app.pagetemplate instead. zope.app.zcmlfiles is a scary package that just pulls in a lot of ZCML that hopefully can vanish entirely over time. 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteers needed!)
Chris McDonough wrote: I tried to go after this today (reversing the dependency setup between zope.formlib and zope.app.form). There are hundreds of changes that need to be made to move interfaces to zope.formlib. I made them (more or less mechanically) but then couldn't get the tests to pass. Since I don't actually use zope.formlib, I don't think it's appropriate that I commit anything. How about you commit it to a branch and let others help you? This particular dependency has annoyed at least me quite a bit ;) Hanno ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteers needed!)
On 5/15/09 7:00 AM, Martijn Faassen wrote: Hey, Chris McDonough wrote: I did a bit of research on the direct zope.app.* dependencies of zope.formlib. Cool! - I looked into its dependency on zope.app.form. It essentially uses a bunch of interfaces from the zope.app.form.interfaces package. I don't know whether it would be reasonable to move all those interfaces to zope.browser or somewhere else, but essentially moving those interfaces to somewhere neutral would break this particular dependency. I think it might make sense to reverse these dependencies - i.e. zope.app.form uses interfaces from zope.formlib for implementing its widgets. The old ZCML-based form mechanism in zope.app.form is moribund anyway so we can just ignore that. Don't know whether this would help the dependency structures though. I tried to go after this today (reversing the dependency setup between zope.formlib and zope.app.form). There are hundreds of changes that need to be made to move interfaces to zope.formlib. I made them (more or less mechanically) but then couldn't get the tests to pass. Since I don't actually use zope.formlib, I don't think it's appropriate that I commit anything. OTOH, I'm pretty convinced that this action would be a win for packages that depend on formlib. I found these: ./zope.app.component-3.7.0-py2.5.egg/EGG-INFO/requires.txt:zope.formlib ./zope.app.exception-3.5.0-py2.5.egg/EGG-INFO/requires.txt:zope.formlib ./zope.app.zcmlfiles-3.5.3-py2.5.egg/EGG-INFO/requires.txt:zope.formlib Are we done yet? ;-) - C ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteers needed!)
Hey, Hanno Schlichting wrote: This is part of the whole named template adapter story. The rationale for the whole story is to be able to replace the template of a view without touching the view. So the template is looked up as an adapter and not just accessed as self.index / self.template. Personally I find the whole feature just annoying and overcomplicated. I think the whole feature is due for removal. It's only used in a very minor number of cases and not consistently with views in general. Could you comment on the discussion I've had with Michael Howitz elsewhere in this thread about this then? I think this relates to the whole z3c.template and zope.formlib discussion. [suggestion to invert the dependency between zope.formlib and zope.app.form] Ah, great minds... 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteers needed!)
Hey, Chris McDonough wrote: [snip a lot of places where these interfaces are used] I'm sure these interfaces are used all over the place as they're used to help implement widgets; we can't just remove them from their original location, but... It's also apparently documented in Phillip's book. So... what? E... I dunno. The interfaces are: from zope.app.form.interfaces import IInputWidget, IDisplayWidget from zope.app.form.interfaces import InputErrors, WidgetInputError from zope.app.form.browser.interfaces import IWidgetImportErrorView Any thoughts? What would happen if we moved them to zope.formlib and left backwards compatibility imports in place in zope.app.formlib? I think it makes sense for zope.formlib to specify its widget interfaces, and zope.app.form to implement a bunch of those widgets. We can also consider (possibly as a separate later step) moving at least some widget implementations themselves into zope.formlib and just leave the old ZCML form stuff behind in zope.app.form (and a lot of backward compat code). We should only move those things into zope.formlib that don't increase its dependencies though, so we can't move everything. 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteers needed!)
Am 13.05.2009 um 19:55 schrieb Martijn Faassen: [...] From this little graph, it looks clear we could do some of the following things (research is needed to see how difficult they are): * cut the dependency of zope.app.publisher on zope.app.component * OR cut the dependency of zope.app.component on zope.formlib * cut the dependency of zope.app.publisher on zope.app.publication * OR cut the dependency of zope.app.component on zope.app.security * cut the dependency of zope.app.publisher on zope.app.publication * OR cut the dependency of zope.app.publication on zope.app.exception * OR cut the dependency of zope.app.exception on zope.formlib The last option I already implemented on the icemac_no_formlib branch in zope.app.exception. z3c.template is used there instead of zope.formlib. I can merge this branch in the next days and cut a release. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteers needed!)
Hi there, Michael Howitz wrote: z3c.template is used there instead of zope.formlib. I can merge this branch in the next days and cut a release. I'm worried by the amount of *new* code that is pulled in just to reduce a dependency. Making this change would pull in *more* dependencies, not less! Not only do we pull in z3c.template, this package also pulls in z3c.ptcompat, which in turn needs extras to actually work. As Roger says this is a compatibility layer, and that isn't pretty either. We shouldn't pull in new code to reduce dependencies. Any new code added into the Zope Toolkit and that shouldn't be done without a discussion (and not done as a minor dependency refactoring). zope.app.exception defines views that pull in standard_macros. I'm not sure the Zope Toolkit should be concerned with views at all at this stage. I'd like to consider moving the whole page template story off into its own area at some point that is not core to the Toolkit, so it's easy to use other templating systems. The only reason zope.app.publication appears to be depending on zope.app.exception is because it needs ISystemErrorView. It's used once somewhere deep within complex exception handling code. I propose we move ISystemErrorView from zope.app.exception into zope.browser, hopefully cutting zope.app.exception out of the dependency tree entirely. 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteers needed!)
On 5/13/09 1:55 PM, Martijn Faassen wrote: Hi there, zope.app.publisher is depended on by quite a bit of code that uses the Zope Toolkit, as it defines brower:view and browser:resource and the like. Unfortunately zope.app.publisher currently depends on more than 60 packages. This is rather excessive, and we'd like to cut down on this. Also interesting about zope.app.publisher is that while it defines a 'browser' directory it actually doesn't contain any ZMI code; instead ZCML directives are defined there. Refactoring so the ZMI isn't around anymore is usually a good first step, but that's not needed here. If you look at the dependency graph for zope.app.publisher the task of fixing this looks daunting: http://startifact.com/depgraphs/zope.app.publisher.svg But now please observe the following: http://startifact.com/depgraphs/zope_app_publisher_cycles.svg This identifies the main cycles in that dependency graph. If we break those in the right way, we can cut down a lot of dependencies in one go. Getting rid of the zope.app.form and zope.formlib dependencies looks like a sensible step. From this little graph, it looks clear we could do some of the following things (research is needed to see how difficult they are): * cut the dependency of zope.app.publisher on zope.app.component * OR cut the dependency of zope.app.component on zope.formlib * cut the dependency of zope.app.publisher on zope.app.publication * OR cut the dependency of zope.app.component on zope.app.security * cut the dependency of zope.app.publisher on zope.app.publication * OR cut the dependency of zope.app.publication on zope.app.exception * OR cut the dependency of zope.app.exception on zope.formlib There are probably a few more options there, but given that small graph, you get the picture. Any volunteers to do this research on how hard some of these steps would look and report back here? Once we've discussed the options we can proceed fixing the problem. I did a bit of research on the direct zope.app.* dependencies of zope.formlib. - I was able to get rid of a dependency on zope.app.container by requiring zope.browser=1.1 (which Tres released yesterday); this package now has the ``IAdding`` interface that zope.formlib relies upon. - I looked into its dependency on zope.app.pagetemplate. It defines two named templates in its form.py module using The ViewPageTemplateFile class from zope.app.pagetemplate. Each is registered in its configure.zcml as adapter with the name default. I don't have enough zen to know what the intent is here or whether the named templates could use zope.pagetemplate instead. - I looked into its dependency on zope.app.form. It essentially uses a bunch of interfaces from the zope.app.form.interfaces package. I don't know whether it would be reasonable to move all those interfaces to zope.browser or somewhere else, but essentially moving those interfaces to somewhere neutral would break this particular dependency. - C ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteers needed!)
Chris McDonough wrote: I did a bit of research on the direct zope.app.* dependencies of zope.formlib. - I looked into its dependency on zope.app.pagetemplate. It defines two named templates in its form.py module using The ViewPageTemplateFile class from zope.app.pagetemplate. Each is registered in its configure.zcml as adapter with the name default. I don't have enough zen to know what the intent is here or whether the named templates could use zope.pagetemplate instead. This is part of the whole named template adapter story. The rationale for the whole story is to be able to replace the template of a view without touching the view. So the template is looked up as an adapter and not just accessed as self.index / self.template. Personally I find the whole feature just annoying and overcomplicated. I think the whole feature is due for removal. It's only used in a very minor number of cases and not consistently with views in general. - I looked into its dependency on zope.app.form. It essentially uses a bunch of interfaces from the zope.app.form.interfaces package. I don't know whether it would be reasonable to move all those interfaces to zope.browser or somewhere else, but essentially moving those interfaces to somewhere neutral would break this particular dependency. Why not move the interfaces to zope.formlib and invert the dependency, so zope.app.form depends on zope.formlib? Or are these generally useful outside of a formlib context? Hanno ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteers needed!)
On 5/14/09 6:09 PM, Chris McDonough wrote: On 5/13/09 1:55 PM, Martijn Faassen wrote: Hi there, zope.app.publisher is depended on by quite a bit of code that uses the Zope Toolkit, as it defines brower:view and browser:resource and the like. Unfortunately zope.app.publisher currently depends on more than 60 packages. This is rather excessive, and we'd like to cut down on this. Also interesting about zope.app.publisher is that while it defines a 'browser' directory it actually doesn't contain any ZMI code; instead ZCML directives are defined there. Refactoring so the ZMI isn't around anymore is usually a good first step, but that's not needed here. If you look at the dependency graph for zope.app.publisher the task of fixing this looks daunting: http://startifact.com/depgraphs/zope.app.publisher.svg But now please observe the following: http://startifact.com/depgraphs/zope_app_publisher_cycles.svg This identifies the main cycles in that dependency graph. If we break those in the right way, we can cut down a lot of dependencies in one go. Getting rid of the zope.app.form and zope.formlib dependencies looks like a sensible step. From this little graph, it looks clear we could do some of the following things (research is needed to see how difficult they are): * cut the dependency of zope.app.publisher on zope.app.component * OR cut the dependency of zope.app.component on zope.formlib * cut the dependency of zope.app.publisher on zope.app.publication * OR cut the dependency of zope.app.component on zope.app.security * cut the dependency of zope.app.publisher on zope.app.publication * OR cut the dependency of zope.app.publication on zope.app.exception * OR cut the dependency of zope.app.exception on zope.formlib There are probably a few more options there, but given that small graph, you get the picture. Any volunteers to do this research on how hard some of these steps would look and report back here? Once we've discussed the options we can proceed fixing the problem. I did a bit of research on the direct zope.app.* dependencies of zope.formlib. - I was able to get rid of a dependency on zope.app.container by requiring zope.browser=1.1 (which Tres released yesterday); this package now has the ``IAdding`` interface that zope.formlib relies upon. - I looked into its dependency on zope.app.pagetemplate. It defines two named templates in its form.py module using The ViewPageTemplateFile class from zope.app.pagetemplate. Each is registered in its configure.zcml as adapter with the name default. I don't have enough zen to know what the intent is here or whether the named templates could use zope.pagetemplate instead. - I looked into its dependency on zope.app.form. It essentially uses a bunch of interfaces from the zope.app.form.interfaces package. I don't know whether it would be reasonable to move all those interfaces to zope.browser or somewhere else, but essentially moving those interfaces to somewhere neutral would break this particular dependency. - C Wrt a possible future for zope.catalog, I think we might leave it be, and encourage framework writers to use repoze.catalog instead. For instance, a new zope.app.catalog package could be written that depends on repoze.catalog. repoze.catalog is a ZODB catalog implementation inspired by zope.catalog. It uses zope.index subclasses for its index implementations. It has a direct dependency on zope.index; that is actually its only direct dependency. (although zope.index depends on ZODB, so that obviously gets pulled down too when you install it, plus its transitives). The trick it uses to avoid inappropriate dependencies is to make the framework writer register event subscribers for IObjectModifiedEvent and its the framework's equivalent of IIntIdRemovedEvent, etc instead of providing the handlers itself. A framework developer could wrap repoze.catalog in such a way that these things happened like they do in zope.catalog; just register appropriate subscribers. It also returns sets of integer docids rather than a result set that knows innately how to resolve these integer ids. A framework developer could obviously create a subclass or adapter that wrapped the catalog and did the object resolution. http://svn.repoze.org/repoze.catalog/trunk/ - C ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteers needed!)
On 5/14/09 6:36 PM, Hanno Schlichting wrote: Chris McDonough wrote: I did a bit of research on the direct zope.app.* dependencies of zope.formlib. - I looked into its dependency on zope.app.pagetemplate. It defines two named templates in its form.py module using The ViewPageTemplateFile class from zope.app.pagetemplate. Each is registered in its configure.zcml as adapter with the name default. I don't have enough zen to know what the intent is here or whether the named templates could use zope.pagetemplate instead. This is part of the whole named template adapter story. The rationale for the whole story is to be able to replace the template of a view without touching the view. So the template is looked up as an adapter and not just accessed as self.index / self.template. Personally I find the whole feature just annoying and overcomplicated. I think the whole feature is due for removal. It's only used in a very minor number of cases and not consistently with views in general. - I looked into its dependency on zope.app.form. It essentially uses a bunch of interfaces from the zope.app.form.interfaces package. I don't know whether it would be reasonable to move all those interfaces to zope.browser or somewhere else, but essentially moving those interfaces to somewhere neutral would break this particular dependency. Why not move the interfaces to zope.formlib and invert the dependency, so zope.app.form depends on zope.formlib? Or are these generally useful outside of a formlib context? That's possible. A Google search indicates that zope.app.form.interfaces is being used by: - zope.formlib - schooltool - plone (maybe) - alchemist - sputnik (an openplans project) - collective.easyslider - zc.extjs - zenoss - alphaflow It's also apparently documented in Phillip's book. So... what? E... I dunno. The interfaces are: from zope.app.form.interfaces import IInputWidget, IDisplayWidget from zope.app.form.interfaces import InputErrors, WidgetInputError from zope.app.form.browser.interfaces import IWidgetImportErrorView Any thoughts? - C ___ 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 )
[Zope-dev] zope.app.publication dependencies (volunteers needed!)
Hi there, zope.app.publisher is depended on by quite a bit of code that uses the Zope Toolkit, as it defines brower:view and browser:resource and the like. Unfortunately zope.app.publisher currently depends on more than 60 packages. This is rather excessive, and we'd like to cut down on this. Also interesting about zope.app.publisher is that while it defines a 'browser' directory it actually doesn't contain any ZMI code; instead ZCML directives are defined there. Refactoring so the ZMI isn't around anymore is usually a good first step, but that's not needed here. If you look at the dependency graph for zope.app.publisher the task of fixing this looks daunting: http://startifact.com/depgraphs/zope.app.publisher.svg But now please observe the following: http://startifact.com/depgraphs/zope_app_publisher_cycles.svg This identifies the main cycles in that dependency graph. If we break those in the right way, we can cut down a lot of dependencies in one go. Getting rid of the zope.app.form and zope.formlib dependencies looks like a sensible step. From this little graph, it looks clear we could do some of the following things (research is needed to see how difficult they are): * cut the dependency of zope.app.publisher on zope.app.component * OR cut the dependency of zope.app.component on zope.formlib * cut the dependency of zope.app.publisher on zope.app.publication * OR cut the dependency of zope.app.component on zope.app.security * cut the dependency of zope.app.publisher on zope.app.publication * OR cut the dependency of zope.app.publication on zope.app.exception * OR cut the dependency of zope.app.exception on zope.formlib There are probably a few more options there, but given that small graph, you get the picture. Any volunteers to do this research on how hard some of these steps would look and report back here? Once we've discussed the options we can proceed fixing the problem. 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 )
