Re: [Zope3-dev] Heads up: I'm about to merge the jim-adapter branch
Jim Fulton wrote: I'm about to merge the jim-adapter branch. This branch has three major refactorings on it: - A redesign of the adapter registration machinery Hey, just some feedback and kudos to you, Jim. Component registration is now indeed a lot more simple, and more flexible. The ability to have a utility managed in content space is very useful, for instance. One pitfall for people is that just registering a utility is not enough - utilities that were in the site management folder before still need to be placed somewhere now of course, as they tend to rely on being located (for instance authentication utilities look up the next utility). Is it possible to have completely non-persistent local utilities in the new world? Thanks! Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Heads up: I'm about to merge the jim-adapter branch
Martijn Faassen wrote: Jim Fulton wrote: I'm about to merge the jim-adapter branch. This branch has three major refactorings on it: - A redesign of the adapter registration machinery Hey, just some feedback and kudos to you, Jim. Component registration is now indeed a lot more simple, and more flexible. The ability to have a utility managed in content space is very useful, for instance. One pitfall for people is that just registering a utility is not enough - utilities that were in the site management folder before still need to be placed somewhere now of course, as they tend to rely on being located (for instance authentication utilities look up the next utility). Is it possible to have completely non-persistent local utilities in the new world? Not entirely sure what you mean ny non-persistent. Assuming that you mean not stored in the database, then yes, by creating a non-persistent component registry and making it a site manager or making it a base of a persistent site manager. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Heads up: I'm about to merge the jim-adapter branch
On Wednesday 26 April 2006 20:42, Jim Fulton wrote: I've tested the branch against a major Zope 3 application here at Zope Corporation. In doing so, I've found and fixed lots of backward compatibility issues. I encourage you to try your applications with the trunk after the merge. If you find problems, put them in the collector and we'll fix them as soon as we can. I will start testing the stuff right away. You will probably get reports during the day. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Heads up: I'm about to merge the jim-adapter branch
Florian Lindner wrote: Am Donnerstag, 27. April 2006 02:42 schrieb Jim Fulton: I'm about to merge the jim-adapter branch. This branch has three major refactorings on it: My project fails (on zope startup) with: from zope.app.zapi import getUtility, getView, absoluteURL, getMultiAdapter ImportError: cannot import name getView My project is probably easy to fix but it cannot be started right now. Should I file a collector item for that? Yes. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Heads up: I'm about to merge the jim-adapter branch
I'm about to merge the jim-adapter branch. This branch has three major refactorings on it: - A redesign of the adapter registration machinery This work: o Provides some performance improvments. + Request per second improved from 7-58% for the cases I tested. + About an 45% reduction in startup time. + About a 50% reduction in time to run the tests. I think this sets the stage for additional improvements in the future. o Set the stage for a super-lookup mechanism (like Python's super builtin), and for named subscribers. - A major simplification of local component management See zope.component.interfaces.IComponentRegistry. - A flexible system for combining component registries. - A beginning of the migration of packages out of zope.app. - A new package for doing deferred imports. This allows you to make names available at the package level without creating circular imports. See zope.deferredimport and see zope.component.__init__ for examples of it's use. This package also provides a way to deprecate names in a module. I've tested the branch against a major Zope 3 application here at Zope Corporation. In doing so, I've found and fixed lots of backward compatibility issues. I encourage you to try your applications with the trunk after the merge. If you find problems, put them in the collector and we'll fix them as soon as we can. You will probably get lots of deprecatuion warnings. Enjoy. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
