[Zope-dev] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Thu Aug 20 12:00:00 2009 UTC to Fri Aug 21 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Thu Aug 20 20:43:37 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012344.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Thu Aug 20 20:45:37 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012345.html Subject: OK : Zope-2.12 Python-2.4.6 : Linux From: Zope Tests Date: Thu Aug 20 20:47:37 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012346.html Subject: OK : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Thu Aug 20 20:49:37 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012347.html Subject: OK : Zope-2.12-alltests Python-2.4.6 : Linux From: Zope Tests Date: Thu Aug 20 20:51:37 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012348.html Subject: OK : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Thu Aug 20 20:53:38 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012349.html Subject: OK : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Thu Aug 20 20:55:38 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012350.html Subject: OK : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Thu Aug 20 20:57:38 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012351.html ___ 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] ZTK with no test failures on Python 2.4, 2.5 and 2.6!
2009/8/20 Fabio Tranchitella kob...@kobold.it: with the today's changes, the KGS for the Zope Toolkit[1] has no build failures on Python 2.4, 2.5 and 2.6 for both 32bit and 64bit Linux. Great news! If you are interested, please get in touch with me and I will provide you the configuration details. Yes please. -- Sebastien Douche sdou...@gmail.com Twitter: http://bit.ly/afkrK (agile, python, open source) ___ 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] Proposal: zope.app.publisher refactoring
Hi all. I think it's time to clean the mess in the zope.app.publisher package. Currently it contains many things that could be moved into separate packages or merged with base zope packages. So here's a sketch plan about where to move things: Menu mechanism (the browser:menuItem directive and friends) - move this to the new zope.browsermenu package. This should be easy as nothing else in zope.app.publisher seem to depend on menus. Browser view directives (browser:page and friends) - move this to some zope.browserpage package and make its structure more clean, so people could understand the magic of browser page class generation. :-) BrowserSkinsVocabulary - this can be moved to zope.publisher.browser and rewritten with zope.schema's SimpleVocabulary not to introduce dependency on zope.componentvocabulary. ManagementViewSelector (the @@SelectedManagementView.html view) - leave it there as is. Resource mechanism (files, directories, etc.) - probably the most complicated code, but it should be easy to move it to the new zope.browserresource package. One problem is with PageTemplateResource that introduces a dependency on zope.pagetemplate. It should probably moved to another package, like zope.ptresource and made dependent on z3c.ptcompat to support chameleon engine. ModifiableBrowserLanguages implementation - move to zope.publisher.browser. It's the useful thing that won't introduce any new dependencies. date fieldconverter - I don't think anyone uses it, I'd leave it there as is and forget about it :) http.zcml - this file contains security declarations for zope.publisher's HTTP-related classes. move them to zope.publisher. xmlprc - move the IXMLRPCView interface and XMLRPCView base class to zope.publisher as a counterpart to zope.publisher.browser.BrowserView. Move MethodPublisher, MethodTraverser, xmlrpc:view ZCML directive to new zope.xmlrpcview package. Also I'd merge MethodTraverser with MethodPublisher to make it easier to understand and to decrease number of entities :) IXMLRPCPublisher adapters for zope.container - move them to zope.container. The IBrowserPublisher adapters that are already there, so it won't make things worser. The zope.container package may be refactored later to break dependency on zope.publisher though. IHTTPView and IFTPView interfaces - move that into zope.publisher as a counterpart to IBrowserView. (BTW, shouldn't IBrowserView be a subclass of IHTTPView?) IFTPDirectoryPublisher interface - not sure what's this and where is it used. Probably should be moved to zope.publisher.interfaces.ftp as well. ILogin, ILogout from zope.app.publisher.interfaces.http - looks like these don't really mean anything and are used only in zope.app.security. I'd move them to zope.app.security even without BBB imports (not to make zope.app.publisher dependent on zope.app.security), but maybe I just don't know something about them? :) That's all for now. I'd like to see some comments/propositions/objections before I start. Also, maybe there are more beautiful names for new packages? After refactorings it will be much easier to clean and develop features that are currently provided by zope.app.publisher. For instance I'd like to try to simplify browser resources code somewhat, but it's for another proposal :) -- WBR, Dan Korostelev ___ 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] Deprecated code in zope.location
Hello, we deprecated locationCopy and CopyPersistent from zope.locaton.pickling with the 3.5.3 release (which should have been a new major release, by the way). This introduced a new dependency on zope.deferredimport, but I just realized that according to the decisions taken by the streering group, the right way to deprecate code is to *not* use zope.deferredimport: http://docs.zope.org/zopetoolkit/steeringgroup/decisions.html I thus propose to stop using zope.deferredimport in core ZTK packages, as stated in the page I mentioned above, unless a new decision is made by who is in charge of making decisions. What about removing the use of zope.deferredimport from zope.location and make a new major release of zope.location? Thanks, Fabio ___ 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] Deprecated code in zope.location
2009/8/21 Fabio Tranchitella kob...@kobold.it: we deprecated locationCopy and CopyPersistent from zope.locaton.pickling with the 3.5.3 release (which should have been a new major release, by the way). Sorry, that was my bad, I didn't care much about versioning when I was making those refactorings with zope.copy. This introduced a new dependency on zope.deferredimport, but I just realized that according to the decisions taken by the streering group, the right way to deprecate code is to *not* use zope.deferredimport: Well, IIRC that change was released before the decision about deprecation warnings was finally taken, so it should be fixed now. What about removing the use of zope.deferredimport from zope.location and make a new major release of zope.location? +1, just change that to plain imports with # BBB comments. -- WBR, Dan Korostelev ___ 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] Proposal: zope.app.publisher refactoring
* 2009-08-21 21:07, Dan Korostelev wrote: IXMLRPCPublisher adapters for zope.container - move them to zope.container. The IBrowserPublisher adapters that are already there, so it won't make things worser. The zope.container package may be refactored later to break dependency on zope.publisher though. -1, I think this is bad and we shouldn't do it: zope.container has nothing to do with the publisher, and it shouldn't depend on it. The fact that we already have the adapters for IBrowserPublisher shouldn't be a reason to bring more publisher-related stuff over there. Fabio ___ 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] Proposal: zope.app.publisher refactoring
2009/8/21 Fabio Tranchitella kob...@kobold.it: * 2009-08-21 21:07, Dan Korostelev wrote: IXMLRPCPublisher adapters for zope.container - move them to zope.container. The IBrowserPublisher adapters that are already there, so it won't make things worser. The zope.container package may be refactored later to break dependency on zope.publisher though. -1, I think this is bad and we shouldn't do it: zope.container has nothing to do with the publisher, and it shouldn't depend on it. The fact that we already have the adapters for IBrowserPublisher shouldn't be a reason to bring more publisher-related stuff over there. Sorry, I didn't explain correctly. Those things are actually simply two ZCML declarations that register traversers that are already defined in zope.container.traversal and used for browser traversing. See for yourself - zope/app/container/xmlrpc/configure.zcml. I think those zcml declarations should be placed together with browser adapter registrations, so people who will be refactoring zope.container could see them. :) -- WBR, Dan Korostelev ___ 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] UnicodeDecodeError problems with Zope 2.12.0b4
Hi All, I'm suffering with two different types of UnicodeDecodeError with a Zope 2.12 project... The first type of problem occurs when a form is submitted and the form fields contain encoded strings. Somewhere down the line I get: Module zope.i18n, line 166, in interpolate Module zope.i18n, line 161, in replace UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 5: ordinal not in range(128) So, my question is how do I get strings submitted to the publisher (ideally) end up as unicode objects not encoded strings? Failing that, how do I find out what encoding the browser has provided? The second type of problem only occurs in IE and Safari, where viewing a page that contains some non-ascii-able data: Module ZPublisher.Publish, line 127, in publish Module ZPublisher.mapply, line 77, in mapply Module ZPublisher.Publish, line 47, in call_object Module Products.Five.browser.metaconfigure, line 427, in __call__ Module Products.Five.browser.pagetemplatefile, line 126, in __call__ Module Products.Five.browser.pagetemplatefile, line 60, in __call__ Module zope.pagetemplate.pagetemplate, line 116, in pt_render - Warning: Macro expansion failed - Warning: class 'zope.tal.taldefs.METALError': macro nesting limit (100) exceeded by u'root/standard_template.pt/macros/nav' Module StringIO, line 270, in getvalue UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 10: ordinal not in range(128) Two things are weird here: - Why am I getting a macro nesting limit? This seems to be a recurring problem (excuse the pun) with Zope 2.12 page templates where if there's an error in a standard template, I get this error when a template that uses it is rendered. - Why am I getting this decoding error only with these browsers? Firefox and Chrome work just fine... Is the publisher doing something special with a header these browsers send that IE and Safari are not? If so, how do I make it do the right thing for IE and Safari? cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ 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] Proposal: zope.app.publisher refactoring
2009/8/21 Dan Korostelev nad...@gmail.com: I think it's time to clean the mess in the zope.app.publisher package. Currently it contains many things that could be moved into separate packages or merged with base zope packages. So here's a sketch plan about where to move things: BTW, I am also waiting for comments from a steering group member, as described in ZTK docs :-) -- WBR, Dan Korostelev ___ 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] Proposal: zope.app.publisher refactoring
Hi Dan, I'll provide feedback for a few parts of your proposal. Dan Korostelev wrote: xmlprc - move the IXMLRPCView interface and XMLRPCView base class to zope.publisher as a counterpart to zope.publisher.browser.BrowserView. Move MethodPublisher, MethodTraverser, xmlrpc:view ZCML directive to new zope.xmlrpcview package. Also I'd merge MethodTraverser with MethodPublisher to make it easier to understand and to decrease number of entities :) Few developers care about XML-RPC these days. Most web developers are now working with REST, JSON, and other similar stuff. It's probably best to move all XML-RPC artifacts, including those in zope.publisher, to a single package, so that most developers can safely ignore the XML-RPC code. IXMLRPCPublisher adapters for zope.container - move them to zope.container. The IBrowserPublisher adapters that are already there, so it won't make things worser. The zope.container package may be refactored later to break dependency on zope.publisher though. You need Jim Fulton's input on this. I think his latest opinion is that zope.container should have nothing to do with publishing. IHTTPView and IFTPView interfaces - move that into zope.publisher as a counterpart to IBrowserView. (BTW, shouldn't IBrowserView be a subclass of IHTTPView?) In zope.app land, sometimes IHTTP* really means INonBrowser*. In other words, sometimes people want to define views just for HTTP ports not intended for web browsers. IFTPDirectoryPublisher interface - not sure what's this and where is it used. Probably should be moved to zope.publisher.interfaces.ftp as well. FTP is in the same boat as XML-RPC. Today, very few developers care to provide a dynamic FTP view of anything. WebDAV usually wins over FTP because adding SSL to WebDAV is easy. All FTP artifacts should move to a separate package. That's all for now. I'd like to see some comments/propositions/objections before I start. Also, maybe there are more beautiful names for new packages? The names you proposed seem ok. Shane ___ 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] Proposal: zope.app.publisher refactoring
2009/8/22 Shane Hathaway sh...@hathawaymix.org: Hi Dan, I'll provide feedback for a few parts of your proposal. Thanks Few developers care about XML-RPC these days. Most web developers are now working with REST, JSON, and other similar stuff. It's probably best to move all XML-RPC artifacts, including those in zope.publisher, to a single package, so that most developers can safely ignore the XML-RPC code. That's a good point. After a quick look, it seems to be easy to move xmlrpc-related things from zope.publisher and zope.app.publisher to new zope.xmlrpc package. One problem is how to make BBB imports then. It doesn't look good to me to make zope.publisher dependent on zope.xmlrpc for xmlrpc stuff, but moving things without BBB imports will break applications that currently uses zope.publisher xmlrpc. One option is to use the notorious extra dependencies, but that needs to be discussed. Other options is to start a big refactoring of zope.publisher, but that is a thing I didn't want to do right now, so the third option is to leave these things until zope.publisher refactoring. ;-) IXMLRPCPublisher adapters for zope.container - move them to zope.container. The IBrowserPublisher adapters that are already there, so it won't make things worser. The zope.container package may be refactored later to break dependency on zope.publisher though. You need Jim Fulton's input on this. I think his latest opinion is that zope.container should have nothing to do with publishing. That's true, but see my reply to Fabio Tranchitella on this topic. :-) IHTTPView and IFTPView interfaces - move that into zope.publisher as a counterpart to IBrowserView. (BTW, shouldn't IBrowserView be a subclass of IHTTPView?) In zope.app land, sometimes IHTTP* really means INonBrowser*. In other words, sometimes people want to define views just for HTTP ports not intended for web browsers. Okay then, let's leave the class hierarchy as is :-) IFTPDirectoryPublisher interface - not sure what's this and where is it used. Probably should be moved to zope.publisher.interfaces.ftp as well. FTP is in the same boat as XML-RPC. Today, very few developers care to provide a dynamic FTP view of anything. WebDAV usually wins over FTP because adding SSL to WebDAV is easy. All FTP artifacts should move to a separate package. Then, there's the same option and the same problem as one for XMLRPC, described above. :-) -- WBR, Dan Korostelev ___ 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] Proposal: zope.app.publisher refactoring
2009/8/21 Dan Korostelev nad...@gmail.com: Browser view directives (browser:page and friends) - move this to some zope.browserpage package and make its structure more clean, so people could understand the magic of browser page class generation. :-) Silly me, I forgot that browser page directives have the menu and title arguments to integrate browser pages with menus! But I'd like to see browser pages usable without using that browser menu implementation, so I want to discuss one more proposition: make browser page directives smarter, so they wouldn't depend hadly on menus and support menu item registration for pages only when zope.browsermenu is installed (and raise an error if browsermenu is not installed and user tried to use menu argument). This won't hurt any current zope.app.publisher's users, but can confuse new users who will be learning these zcml directives. But I am sure that good documentation can help here. :-) -- WBR, Dan Korostelev ___ 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 )
