March 2009 - Zope-Dev

zope.publisher dependencies
by Shane Hathaway 06 Mar '09

06 Mar '09

I've been working on the dependencies to and from zope.publisher. Refining the dependencies should make it easier to integrate zope.pipeline when it's ready. I've noticed that nearly all packages that depend on zope.publisher depend only on a few pieces of it: - zope.publisher.interfaces - zope.publisher.browser.Browser{View|Page} - zope.publisher.browser.TestRequest One simple, low-risk refactoring I would like to do is move zope.publisher.interfaces into its own package, make zope.publisher a namespace package, and make zope.publisher depend on zope.publisher.interfaces. The __init__.py in zope.publisher is already empty, so I expect the namespace conversion to be safe. Then I'd like to refine the dependency list of various packages that only require zope.publisher.interfaces. Any objections? It is less clear what we should do with BrowserView and BrowserPage. They depend on zope.location, unlike the rest of zope.publisher, so they don't really fit there. Perhaps those two belong in a new package, "zope.publisher.browserbase". There is also the tiny new "zope.browser" package. Would it make sense to move them there? (It's hard to tell what the intent of the new package is.) I'd love to hear other suggestions. As for TestRequest, I could update the setup.py of various packages that currently depend on zope.publisher just for TestRequest. I would make zope.publisher a test-only requirement. Shane

8 45

Re: [Zope-dev] [Checkins] SVN: zope.file/trunk/ Update package mailing list address. Remove zpkg stuff.
by Benji York 06 Mar '09

06 Mar '09

On Mon, Mar 2, 2009 at 11:38 AM, Dan Korostelev <nadako(a)gmail.com> wrote: > Log message for revision 97423: > Update package mailing list address. Remove zpkg stuff. > Deleted: zope.file/trunk/src/zope/file/zope.file-configure.zcml > =================================================================== > --- zope.file/trunk/src/zope/file/zope.file-configure.zcml 2009-03-02 16:09:01 UTC (rev 97422) > +++ zope.file/trunk/src/zope/file/zope.file-configure.zcml 2009-03-02 16:38:27 UTC (rev 97423) > @@ -1 +0,0 @@ > -<include package="zope.file"/> I believe people still use the ZCML "slug" files like the above. -- Benji York Senior Software Engineer Zope Corporation

5 11

GSOC 2009
by Adam GROSZER 06 Mar '09

06 Mar '09

Hello, There are rumours that Google kicked off the 2009 Summer of Code. Anyone knowing further details? Any chance for us to take part again? -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: Humor is an escape

4 5

Zope Tests: 6 OK
by Zope Tests Summarizer 06 Mar '09

06 Mar '09

Summary of messages to the zope-tests list. Period Thu Mar 5 12:00:00 2009 UTC to Fri Mar 6 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Thu Mar 5 20:22:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011235.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Thu Mar 5 20:24:22 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011236.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Thu Mar 5 20:26:22 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011237.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Thu Mar 5 20:28:27 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011238.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Thu Mar 5 20:30:29 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011239.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Thu Mar 5 20:32:30 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011240.html

1 0

zope.publisher
by Roger Ineichen 06 Mar '09

06 Mar '09

Hi Martijn, Shane I fixed some issues in zope.publisher and at the same time I implemented the default skin pattern within an adapter pattern. The adapter getDefaultSkin in zope.publisher.browser.py is registered in configure.zcml The changes are compatible within the zope core but only if zmcl is used. The concept is the following ---------------------------- A request implementation can provide a named IDefaultSkin adapter within the name "default". This default skin get used if no other default skin get defined. The IDefaultBrowserLayer is used as such a default adapter for IBrowserRequest. This was done hardcoded in setDefaultSkin before my changes. A default skin in your own projects get registered as an unnamed IDefaultSkin adapter. This is normaly done within the defaultSkin ZCML directive. Such a unnamed adapter get used before the setDefaultSkin method will lookup for the *fallback* named adapter. Everything is 100% compatible if the adapter configuration get used in configure.zcml. Questions --------- Everbody, Right now the setDefaultSkin method will silently fail if a skin doesn't provide ISkinType. What do you think should we raise an exception instead of silently ignore the skin? A general problem in the implemenation before and after my changes is that the skin interfaces registered by the defaultSkin ZCMl directive will register the interface as adapter which is not adaptable because it's not an adapter factory. Should we change the defaultSkin directive and register an adapter factory? This whould ensure that we don't have junk in the dapter registry. Another question The applySkin method removes all skin types from the request. Why do we not remove all skin types in setDefaultLayer? Are there any skins applied at the time we call setDefaultSkin? Martijn, Does grok need to register this new adapter somewhere? If the adapter configuration is missing the default skin apply pattern will break. Shane, Can you review and merge this changes into your zope.pipeline branch? Regards Roger Ineichen _____________________________ END OF MESSAGE

3 4

zope3docs -> zopeframework
by Martijn Faassen 05 Mar '09

05 Mar '09

Hi there, I've moved over the documentation zope3docs over into the zopeframework/trunk package. I left the documentation in zope3docs too for now so as not to break the automated web build system. Jens, could you pick up zopeframework/trunk now for http://docs.zope.org/zopeframework? And put a redirect in place for http://docs.zope.org/zope3docs to the new location? We can then retire zope3docs. Regards, Martijn

2 4

Proposals: more refactoring
by Dan Korostelev 05 Mar '09

05 Mar '09

I'd like to continue moving code to saner places, so here's two more little ideas on next refactorings: - Move password managers from zope.app.authentication to a new package, like zope.password. They are really useful in any authentication system, even not related to "zope3 the app server" or zodb at all. That move will ease the reuse of password encoding/checking mechanism in other authentication software, so people won't need to install anything but password manager and zope.interface. The zope.schema is also needed for the password manager vocabulary, but I'm not sure if the vocabulary should go to the new package, because it adds a dependency on zope.schema. What do people think? - Move the functionality of zope.app.principalannotation to new package, zope.principalannotation, leaving only appsetup bootstrap subscriber and browser menu item, as well as compatibility imports in the original package. I'd volunteer to do that little refactorings, if noone objects. -- WBR, Dan Korostelev

2 3

zope3docs -> zopeframework?
by Martijn Faassen 05 Mar '09

05 Mar '09

Hi there, We have an area called 'zope3docs': http://svn.zope.org/zope3docs/ which contains many documents that are actually more about the Zope Framework than the Zope 3 app server. In fact I suspect all of these documents are more about the framework than anything else, so we should move them all over. http://svn.zope.org/zopeframework/trunk/ Opinions? Regards, Martijn

4 7

the Zope Framework Steering Group expands!
by Martijn Faassen 05 Mar '09

05 Mar '09

Hi there, I'm happy to announce that the Zope Framework Steering Group is now bigger than Just Me. Stephan Richter and Christian Theune have now joined the Steering Group, bringing it up to 3 members. I think both don't need much introduction on this mailing list. Since we're now bigger than 1 person we'll have to demonstrate to the skeptics we can reach consensus quickly and clearly! Regards, Martijn

2 1

Dependency of zope.deprecation in zope.configuration
by Baiju M 05 Mar '09

05 Mar '09

Hi, zope.deprecation is used in zope.configuration *only* to turn off deprecation warning when accessing attribute of an object in one place. But there is no test case or comment about when such a warning will occur. I have pasted the relevant code here: def resolve(self, dottedname): """Resolve a dotted name to an object.""" .... try: zope.deprecation.__show__.off() obj = getattr(mod, oname) zope.deprecation.__show__.on() return obj except AttributeError: zope.deprecation.__show__.on() # No such name, maybe it's a module that we still need to import try: return __import__(mname+'.'+oname, *_import_chickens) except ImportError: if sys.exc_info()[2].tb_next is not None: # ImportError was caused deeper raise raise ConfigurationError( "ImportError: Module %s has no global %s" % (mname, oname)) Can anyone point the reasoning behind turning off deprecation warning there. What kind of deprecation is expected, and why it should not be displayed ? Regards, Baiju M

5 5