Re: [Zope-dev] Removing dependency between zope.location and zope.copy
2009/12/22 Fabio Tranchitella kob...@kobold.it: I'm wondering if it would be possible to drop the dependency between zope.location and zope.copy. It makes sense to me because zope.location depends on zope.copy only because it registers a LocationCopyHook, not because it is really using anything from that package. Attached to this message you can find my (proposed) patch to remove the dependency making the adapter registration optional, and informing the developer that zope.copy is needed is he is importing directly the zope.location.pickling module. Comments? Looks okay :) -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: Sandbox/nadako/zope.app.publisher/ Clean up dependencies.
2009/8/27 Stephan Richter srich...@cosmos.phy.tufts.edu: On Thursday 27 August 2009, Hanno Schlichting wrote: To make every policy happy, some new 3.9 release of zope.container and some re-releasing of a no-API-changes 3.8.4 release would be required - quite tedious and not worth it IMHO ;-) I disagree. Somebody did a mistake and should try to fix it. If we keep slipping in minor versions in setup.py, we will eventually bring development to a halt again. Well, I thinked about that, but it was hard to choose the right way. zope.container 3.8.3 doesn't really have any API changes, the only thing that was changed is that two zcml adapter registration was added to configure.zcml (and those adapters were are already in zope.container). No python changes, no dependency changes. Does it really worth a new feature release? New zope.app.publisher needs this adapter registration for its functional tests though, so it won't work with older zope.container versions. Should I release zope.container 3.9.0 and then zope.app.publisher 3.10.0 only because of that thing? (note that it's only a test dependency requirement) -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: Sandbox/nadako/zope.app.publisher/ Clean up dependencies.
2009/8/28 Stephan Richter srich...@cosmos.phy.tufts.edu: On Thursday 27 August 2009, Dan Korostelev wrote: Well, I thinked about that, but it was hard to choose the right way. zope.container 3.8.3 doesn't really have any API changes, the only thing that was changed is that two zcml adapter registration was added to configure.zcml (and those adapters were are already in zope.container). No python changes, no dependency changes. Does it really worth a new feature release? New zope.app.publisher needs this adapter registration for its functional tests though, so it won't work with older zope.container versions. Yes, because people need to be aware that there are now 2 new adapter registrations around, which might in fact interfere with their registrations. Should I release zope.container 3.9.0 and then zope.app.publisher 3.10.0 only because of that thing? (note that it's only a test dependency requirement) Definitely create a zope.container 3.9.0 release. That's done. I forgot what we said about changing dependencies, but I am pretty sure they also always require a major update, so yes, 3.10.0 for zope.app.publisher. Hmm, that change looks more like a bug fix to me (the dependencies were wrong in the previous release of zope.app.publisher and now they are fixed), so may be it should be 3.9.1 nevertheless? -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: zope.app.publisher refactoring
2009/8/25 Martijn Faassen faas...@startifact.com: You have zope.browsermenu, zope.browserpage, zope.browserresource. I propose instead we name them zope.menu, zope.page and zope.resource. -1 These things are really only for browser, and ZCML directives are in browser namespace, while, for example, zope.resource is a quite abstract name that could be taken by more appropriate package in future. I think we can safely claim these names in the 'zope' namespace as these *are* the Zope Toolkit menu, page and resource implementations. I'm not sure if they are reusable without having to buy into the rest of the Zope Toolkit. Currently these packages have a note that they are not reusable, as recommended in steering group decisions list, because they depend on the publishing system, which is a really large part. -- 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] zope.app.publisher refactoring status
2009/8/25 Martijn Faassen faas...@startifact.com: See my comment on naming. I think we should call 'zope.menu', 'zope.page', 'zope.resource'. See my answer there :-) * zope.ptresource - the page template resource that was moved into a separate package to make zope.browserresource independent from zope.pagetemplate. it's now a plugin for zope.browserresource - a custom resource factory, registered for pt, zpt and html extensions. Was it registered for these extensions already? In particular I'm wondering about the 'html' extension - I can see use cases to want to publish non-page template HTML files as static resources. The DirectoryResource was creating page template resources for these extensions, so I just copied the behaviour. I also see the case when simple static HTMLs are needed, I think those cases are most, actually. But pagetemplate resources will work for non-templated HTMLs as well, and people can simply not include zope.ptresource configure.zcml and configure the resource factory for extensions they need. I guess most people won't even install zope.ptresource though, as it's not very useful. ZRT resources are more appropriate for dynamic css's and javascripts, so I think users will prefer it (BTW, it also needs to be adapted for new package). Second, the browser:defaultView and browser:defaultSkin directives. The functionality of default views and default skins is currently contained in zope.publisher, and these directives only provide a way to configure default view/skin via ZCML. I think that these directives should be moved to zope.publisher as well, since it seems the right place for them and the move won't introduce extra dependencies for zope.publisher. zope.publisher indeed already depends, at least indirectly, on zope.configuration. It doesn't define any ZCML directives at this point though, which makes me a bit wary. Then again, zope.security does, and zope.publisher depends on it. So I think this is all right. Okay, that's done :-) Third, the xmlrpc:view directive and the XML-RPC method publisher. It's a nice thing, but people doesn't seem to be interested very much in XML-RPC these days. Also, it seems that zope.publisher will be refactored soon, so the future of xmlrpc modules is not clear. I see two options for this thing: a) Extract it into the new, zope.xmlrpc module. b) Leave it there as is. If noone demonstrates interest in discussing the xmlrpc, I'll probably choose option b :-) Grok at least can't just lose its XML-RPC support, and we'd like to stop importing zope.app.publisher if we can. While I think most people have moved on to using other things than XML-RPC, I do think there's a lot of code out there that does use XML-RPC, and it's so convenient I suspect more code will be written in the foreseeable future. I therefore would like to see a zope.xmlrpc module. I think there is code in other packages as well that could be moved in here. We do need to think about the import situation however. That said, we shouldn't wait for this to be resolved to merge the other changes into the Zope Toolkit. I'll leave it there for now, until XMLRPC and FTP refactorings. There's some PITA with functional tests for this module (or it's just me with not enough experience, whatever), so it'll take some time. I'd like other changes to be merged soon. Finally, it'd be nice if we could give the new KGS system a workout by testing things with that. I hope you can involve Jim in this discussion. Then once we have a way of working figured out, it's important we also record this in the ZTK documentation. Sorry, I also didn't catch up with the list recently, so I don't know about the new KGS system yet. :-) I'll read about it later. -- 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/24 Stephan Richter srich...@cosmos.phy.tufts.edu: On Friday 21 August 2009, Dan Korostelev wrote: BrowserSkinsVocabulary - this can be moved to zope.publisher.browser and rewritten with zope.schema's SimpleVocabulary not to introduce dependency on zope.componentvocabulary. -1. Why? The reason we wrote the zope.componentvocabulary code originally was exactly to avoid the constant reimplementation of that code. Well, the only reason is that zope.publisher currently doesn't depend on zope.componentvocabulary. But it doesn't matter for me personally, so if steering group decides that it's okay to add a dependency on zope.componentvocabulary to zope.publisher, I won't rewrite the vocabulary with SimpleVocabulary :-) -- 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/22 Michael Howitz m...@gocept.com: Am 21.08.2009 um 21:06 schrieb Dan Korostelev: [...] 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? :) z3c.layer.pagelet also uses these interfaces to re-implement login/logout like zope.app.security but by using pagelets and viewlets. So it would be nice to have a better place for these interfaces, so z3c.layer.pagelet does not need to depend on zope.app.security. Are these interfaces used for anything else than just declaring them as implemented? :-) I don't see much sense in them, because they are too abstract and it's hard to understand what they are for, so I'd get just rid of them in z3c.layer.pegelet. -- 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] zope.app.publisher refactoring status
Hi people. As you might notice, I was refactoring zope.app.publisher in my sandbox. The work is mostly done now, apart from couple of things still in question. Four new packages have been introduced: * zope.browsermenu - browser menu system, without any changes. :-) * zope.browserpage - browser:page directive and friends. the directives was changed to support menu item registration only when zope.browsermenu is available, simply ignoring (and raising a warning) the menu argument otherwise. * zope.browserresource - resource system and browser:resource directive and friends. file-based resources now supports pluggable resource class lookup based on file extension (implementation based on this patch - https://bugs.launchpad.net/zope3/+bug/98459). this allows to separate pagetemplate resources into another package as well as support registering specific resource factories for some extensions (.zrt for example). * zope.ptresource - the page template resource that was moved into a separate package to make zope.browserresource independent from zope.pagetemplate. it's now a plugin for zope.browserresource - a custom resource factory, registered for pt, zpt and html extensions. The ModifiableBrowserLanguages adapter was moved into zope.publisher.browser, as well as some ZCML security declarations defined for zope.publisher's classes. Things left in zope.app.publisher are still to be discussed. First, the Browser Skins vocabulary - a vocabulary of IBrowserSkinType utilities. It could be moved to zope.publisher, but it introduces dependency on zope.componentvocabulary, which is not needed for zope.publisher currently. So there's three options to choose from: a) Move it to zope.publisher, introducing a dependency on zope.componentvocabulary for it. b) Move it to zope.publisher, rewriting the vocabulary to use zope.schema's SimpleVocabulary and not introducing dependency on zope.componentvocabulary. c) Leave it there as is. I think, that it's a nice option, since Browser Skins vocabulary doesn't seem to be used anywhere by other zope packages and can be easily recreated if someone will need it. Second, the browser:defaultView and browser:defaultSkin directives. The functionality of default views and default skins is currently contained in zope.publisher, and these directives only provide a way to configure default view/skin via ZCML. I think that these directives should be moved to zope.publisher as well, since it seems the right place for them and the move won't introduce extra dependencies for zope.publisher. Third, the xmlrpc:view directive and the XML-RPC method publisher. It's a nice thing, but people doesn't seem to be interested very much in XML-RPC these days. Also, it seems that zope.publisher will be refactored soon, so the future of xmlrpc modules is not clear. I see two options for this thing: a) Extract it into the new, zope.xmlrpc module. b) Leave it there as is. If noone demonstrates interest in discussing the xmlrpc, I'll probably choose option b :-) The code is available in svn://svn.zope.org/repos/main/Sandbox/nadako/zope.app.publisher/. It will also check out newly created packages via svn:externals, so all you need for testing is simply checkout zope.app.publisher from my sandbox. -- 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] Deprecated code in zope.location
2009/8/23 Fabio Tranchitella kob...@kobold.it: * 2009-08-21 21:15, Dan Korostelev wrote: 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. Would it also be possible to remove the dependency of zope.location on zope.copy? It is only needed to register an adapter for ICopyHook, which can be made optional in the ZCML. To me it looks a wise choice, because zope.location is well usable without zope.copy, and if somebody needs the hook it is because he will be using zope.copy, so he must depend on it. I prepared these changes in a branch, can somebody review them? It seems somewhat strange to have a module that imports from a package that is not in dependencies. Also, zope.copy is a very tiny module with no dependencies beyond zope.interface and no C code, so I don't see any problem with having it in dependencies. However, any option is fine with me, so +0 :-) BTW probably it's better to isolate the copy hook adapter in a submodule with more sane name, like copyhook and deprecate the pickling module, so people could understand those things easier. :-) -- 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] 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 )
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/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 )
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
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 )
Re: [Zope-dev] chameleon.core removes the meta http-equiv=content-type tag
Oh, thanks that you reminded me of that :)) This looks like it migrated from zope.pagetemplate. That shameless removal of content from my template annoyed me as well some time ago, so at last I monkey-patched that method in zope.pagetemplate. I think, we should remove that behaviour from both zope.pagetemplate and chameleon.core, because it's developer' prerogative to decide what to keep and what to remove from the rendered page, not the templating system's. If noone objects, I'll fix it in zope.pagetemplate. 2009/8/14 Fabio Tranchitella kob...@kobold.it: I hope this is the right mailing list for such a question. Why does chameleon.core removes the meta tag http-equiv=content-type from the output? In template.py, line 286: # Look for an encoding specification in the meta tag match = utils.re_meta.search(body) if match is not None: content_type, encoding = match.groups() # TODO: Shouldn't meta/?xml? stripping # be in PageTemplate.__call__()? body = utils.re_meta.sub(, body) else: content_type = None encoding = config.DEFAULT_ENCODING I couldn't find the explanation anywhere in the source code nor in the documentation. -- 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] chameleon.core removes the meta http-equiv=content-type tag
2009/8/14 Jim Fulton j...@zope.com: On Fri, Aug 14, 2009 at 9:07 AM, Dan Korostelevnad...@gmail.com wrote: Oh, thanks that you reminded me of that :)) This looks like it migrated from zope.pagetemplate. That shameless removal of content from my template annoyed me as well some time ago, so at last I monkey-patched that method in zope.pagetemplate. I think, we should remove that behaviour from both zope.pagetemplate and chameleon.core, because it's developer' prerogative to decide what to keep and what to remove from the rendered page, not the templating system's. If noone objects, I'll fix it in zope.pagetemplate. Please get Fred Drake's review before removing this from zope.pagetemplate. According to SVN history, the meta tag stripping was added 4 years ago by Dmitry Vasiliev, not Fred Drake. Or was that done after Fred's approval? :) Okay, anyway, I'll wait for him to return from vacation. -- 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: refactoring of zope.app.security
2009/3/20 Christian Theune c...@gocept.com: - _protections.py module. It defines a NoProxy checker for zope.i18nmessageid.Message and adds __name__ and __parent__ attributes to _available_by_default. This module was executed in zope.app.security.__init__ and generally does useful things for most of applications. The problem is that neither zope.i18nmessage, nor zope.location already depend on zope.security. One solution is to move the protections in that packages, placing the code into try/except ImportError block to avoid hard dependency. That last solution seems reasonable. I think Christian Theune has had some dealings with a strategy like this during our dependency refactoring sprint; Christian? Sorry, I've stared at the issue for a while but can't remember that I had (something like) that during the sprint. It's nevermind now :) I just added those protections to zope.security itself. -- 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] setting missing minimum version in setup.py
2009/3/16 Martijn Faassen faas...@startifact.com: There is a compromise I am willing to take. If package zope.bar depends on a *new feature* or *feature change* in zope.foo 1.3.x, then it should specify the version. In other words specifying open restrictions on the major version levels is okay, but never on the bug fix level. (I just hope this does not bite us later. ;-) Yes, I was thinking in this direction too. I can see this as more of an issue with bug fixes than with feature changes. This means that requirements can only say zope.foo = x.y, and never zope.foo = x.y.z. What do people think? That looks sane, so I'm +1 :) -- 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] [Checkins] SVN: z3c.layer.pagelet/trunk/ Removed dependency on``zope.app.security`` by using the new packages``zope.authentication`` and ``zope.principalregistry``.
2009/3/16 Michael Howitz m...@gocept.com: Am 16.03.2009 um 16:43 schrieb Roger Ineichen: [...] It's a pagelet implementation of login/logout, so I thought it matches the goal of this package very well. Yes and No. It's of corse usefull to have predefined login views available. But I use a z3c.form based implementation for this. I thought this as the next step: the template for cookie login is not really nice and makes wrong assumptions (e. g. unauthenticated principal has the id zope.anybody). So I planned to replace it with a z3c.form based login form. But this would add a new dependency and I was not sure if this is a good idea. Look at my latests changes in zope.app.authentication loginForm template, it cleans up the template by separating camefrom/unauthenticated logic into a python class. I think you should do the same for your implementation. -- 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] zope:view directive
2009/3/16 Michael Howitz m...@gocept.com: zope.container has a similar problem: its configure.zcml uses zope:view directives. When I'd like to use zope.container in a Zope 3 the application server environment I have to know that zope:view is defined in zope.app..component or I have to find it out. There is no dependency, not test and no documentation mentioning this inside zope.container. BTW, what's zope:view was created for? Shouldn't we just move from zope:view to simple zope:adapter and deprecate zope:view to get rid of confusion? -- 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] Dependencies on zope.app.appsetup
Hi there. One of most annoying dependencies is the zope.app.appsetup package. Some packages, like zope.session depend on it just to provide boostrap setup for using these packages in context of zope3, the application server, however, they can be greatly used without it, so this is really awful dependency. I saw that, on last sprint, the subscriber for error reporting utility was moved from zope.error to zope.app.appsetup, so zope.error could lose the dependency on zope.app.appsetup. So, the first question is: do we want to move all subscribers like that? It doesn't seem like a best solution though, because then zope.app.appsetup should depend on all those packages, like zope.session. :-/ The problem is that the bootstrap code in zope.app.appsetup is really zope3, the application-specific, so it uses root folders, persistent site managers, site management containers, ZopePublication.root_name, and so on. The code itself is okay, because it provides an easy way to setup misc. components for the zope3 application server, but still it's a problem, because it's probably impossible to refactor it in a application-independent way (until we provide some cool pluggable application bootstrapping mechanism, which is probably will become too complex and not needed/used by most application developers). So, the general question is where should we move the bootstrap setup code? Or, alternatively, we could just leave it in place, but greatly separate it from another package components and provide zope.app.appsetup as an extra dependency (sigh...). Ideas? -- 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] zope.site
2009/3/13 Christian Theune c...@gocept.com: On Thu, 2009-03-12 at 22:00 +0300, Dan Korostelev wrote: Please, can someone review the current zope.site's trunk? It fails the persistent_interfaces tests. I didn't ever work with persistent code, so I don't have idea about what's going on. But I'd like to make a release of this package. For me this t est works but the following tests fail: zope.site.tests.test_folder zope.site.tests.test_localsitemanager zope.site.tests.test_registration zope.site.tests.test_site That's strange. Are you sure that you're testing with latest versions of other packages? -- 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] zope.app.security refactoring results
Hey there! The refactoring of zope.app.security is now generally done. In the process, three new packages has been created: * zope.authentication - the most interesting and small. It contains the IAuthentication contract, as well as IUnauthenticatedPrincipal/IAuthenticatedGroup and company. Beyond that, it also contains several utilities related to principal lookup - the PrincipalLookupError and PrincipalSource/PrincipalTerms. * zope.principalregistry - it's an implementation of IAuthentication that's based on global non-persistent registry object. It provides zcml-based principal creation. Yes, it's the global principal registry from zope.app.security. * zope.localpermission - the implementation of persistent/local permission class that can be added and used per-site. It's a bit of (possibly deprecated) TTW development. I created another thread about possibility of death of local permisions, so may be this package will be named zope.app.localpermission and forgotten forever. :) Also, two other packages were touched: * zope.security - here migrated some bits of zope.app.security - the NoProxy definition for zope.i18nmessageid.Messages, the permission vocabularies, zcml definitions of some common permissions, like zope.View. * zope.publisher - here migrated the adapter from IPrincipal to ILoggingInfo and the adapters from zope.publisher's HTTP/FTP requests to ILoginPassword. May be they will be moved again, when we'll be doing zope.publisher's refactorings. One nice feature provided as a result of refactoring is possiblity of the authentication system to be used without of zope.publisher. The zope.app.authentication and z3c.authenticator probably can be modified/refactored not to depend on zope.publisher as well, but it will be another task. The original zope.app.security now only contains browser views and BBB imports. Other packages still need to be adapted to new imports, but I'd like to do that after releasing refactored packages. I already adapted zope.securitypolicy and zope.app.authentication though. It's a big win for zope.securitypolicy that it doesn't pull the whole zope anymore. Please, check it out and say your opinion. I'd like new packages to be released ASAP. :-) -- 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] zope.app.security refactoring results
2009/3/13 Dan Korostelev nad...@gmail.com: The refactoring of zope.app.security is now generally done. In the process, three new packages has been created: [snip] Please, check it out and say your opinion. I'd like new packages to be released ASAP. :-) BTW, now when we have a steering group, I'd like my changes to be approved by 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 )
Re: [Zope-dev] Death of local/persistent permissions (zope.app.security refactoring)
2009/3/13 Dan Korostelev nad...@gmail.com: 2009/3/11 Martijn Faassen faas...@startifact.com: - Move LocalPermission into new zope.localpermission package. I personally didn't ever need local permissions. You're talking about locally defined permissions, correct, not about giving someone a permission locally? I'm talking about local persistent permissions that can be added to ZODB and registered per site. It's zope.securitypolicy that gives local permissions, so, LocalPermission has nothing to do with local grants. Right, that's what I thought. Agreed they should go off into a package on its own, probably to eventually die. :) (I have bad memories of struggling with this stuff in a sprint in 2003). Thinking now. If we want local persistent permissions to be considered dead and we want to discourage their usage, may be the package should be called zope.app.localpermission then? If so, we could also move its ZMI views there and forget about that package. :) It's just because zope.localpermission name sounds like some nice part of zope framework, but in reality, the functionality provided by the package is deprecated for use withing _the framework_. But, do we really want it deprecated and dead? May be there's some nice use cases for it? Anyone? Martijn, Stephan, anyone? This question is the only thing that stops me from releasing refactored packages. Personally, I quite like the idea of naming it zope.app.localpermission, merging it with its views (possibly as an optional dependency) and forgetting about it. But it's just because I didn't ever need and probably won't ever need local permissions, so it's one of some old and deprecated patterns to me. So, if noone will object/reply soon, I'll rename the package and finally release the refactorings. -- 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] New package: zope.authentication AND the problem.
2009/3/12 Martijn Faassen faas...@startifact.com: Dan Korostelev wrote: [snip] Another solution which I like much less is to move those adapters to zope.authentication and define an extra dependency (sigh) on zope.publisher, but then the package won't be so nice, clean and generic as it could be. :-) One question I have is how theoretical this genericity is. Do we have concrete use cases for using this zope.authentication outside of a Zope context? What would that look like? Do we really expect people to show up and say: hey, I'll use this for my project that doesn't use zope.publisher at all!. It can be very useful if someone wants to implement pluggable authentication system to use with zope.component/zope.security but with custom request implementations. However, it's hard for me to say if anyone will show up and talk about that use case, because 99% that I won't be that guy. :-) So, no concrete use cases yet. We can also ask it in another way: if zope.authentication were not to depend on zope.publisher, would zope.principalregistry not depend on zope.publisher either? Yes, zope.principalregistry does the adaptation of an abstract request object to ILoginPassword to get credentials and issue challenges, so if we provide an adapter for another request implementation, it will work fine without any changes. I can easily write a really simple adapter from webob.Request to ILoginPassword and use zope.principalregistry with it, without any zope.publisher/publication context. What about zope.app.authentication and z3c.authenticator? (imagining any of their ZMI away for now). Would *those* packages then be useful independently from zope.publisher? Currently, they are using some of implementation bits of zope.publisher, but I think, it's not a very big work to make them request type independent. The only possible difficulties I can think of is the implementation if loginform/cookie plugins. I still feel bad about zope.publisher needing to know about authentication (in the dependency sense) where it doesn't today. Is that really true: does it today really not do anything with authentication? Well, it implements the zope.security's IParticipation and has the setPrincipal method, but the principal is actually set by IPublication object. It also defines and implements the IHTTPCredentials/IFTPCredentials that allow to get login/password and initiate a login challenge, similar to the ILoginPassword, but request-specific. BTW, the classes in questions are the adapters from IHTTPCredentials/IFTPCredentials to the ILoginPassword. -- 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] Release of zope.component (was [Checkins] SVN: zope.component/trunk/ Merge the 'tseaver-wo_zope_deferredimport' branch)
2009/3/12 Martijn Faassen faas...@startifact.com: Hey, Dan Korostelev wrote: I decided to start a new branch of that, because there's no still response on my requests for a release. I see that you have access to that package now. Could you also give srichter access to zope.component? Okay, done. Should we release it as it is currently (with pure-python hookables in itself but with hook extra that still pulls zope.hookable)? -- 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] z3c.form - creating a file upload widget
2009/3/12 Stephan Richter srich...@cosmos.phy.tufts.edu: On Thursday 12 March 2009, Martin Aspeli wrote: I'm writing a custom file widget for z3c.form that works like the Archetypes file widget that Plone uses and the formlib widget in collective.namedfile. That is, after you've uploaded a file once, you're given a radio button to decide whether to upload a new file, or leave the existing file in place. I can't quite figure out how to do this, though. I've tried to override the extract() method on the widget to look in the request for the special marker that says user chose not to change the file. However, I don't know what to return. If I return NOVALUE, then validation fails (if the field is required). If I try to look up the field value from the data manager and return it, it ends up setting the field back on itself, which is wasteful. All great questions and I am not sure I have good answers. I think you want a NONEWVALUE or so marker and have the validator honor it correctly. If you make a proposal to enrich the API, I'll probably agree to it. :-) Just to note, there's already the NOT_CHANGED constant in z3c.form.interfaces. -- 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] Common permissions (final bits of zope.app.security refactoring)
2009/3/12 Martijn Faassen faas...@startifact.com: Thanks very much for this analysis and summary! My comments below. [...snip...] Okay, the move is now done. Anyway, we can always move zope.ManageApplication into zope.app.applicationcontrol when we want to, so leave it in zope.app.security for now. +1 -- 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] Release of zope.component (was [Checkins] SVN: zope.component/trunk/ Merge the 'tseaver-wo_zope_deferredimport' branch)
2009/3/12 Martijn Faassen faas...@startifact.com: Dan Korostelev wrote: 2009/3/12 Martijn Faassen faas...@startifact.com: Hey, Dan Korostelev wrote: I decided to start a new branch of that, because there's no still response on my requests for a release. I see that you have access to that package now. Could you also give srichter access to zope.component? Okay, done. Should we release it as it is currently (with pure-python hookables in itself but with hook extra that still pulls zope.hookable)? Yes, I think that's all right. The work is already done and we risk the least in losing performance. Okay, it's released now. Expect some test breakage for the first time, until we adapt our packages to the removal of bbb interfaces. I'll try to do that quickly and then run the KGS and compat tests. -- 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] zope.site
Please, can someone review the current zope.site's trunk? It fails the persistent_interfaces tests. I didn't ever work with persistent code, so I don't have idea about what's going on. But I'd like to make a release of this package. Anyone? -- 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: refactoring of zope.app.security
2009/3/11 Roger Ineichen d...@projekt01.ch: Betreff: [Zope-dev] Proposal: refactoring of zope.app.security - Move IAuthentication and other interfaces into new zope.authentication package. Also move there PrincipalSource and the checkPrincipal utility function. Also move there the PrincipalTerms class, however that will add dependency on zope.browser (which is really really tiny, as you may know). Should we move the password managers registry and vocabulary to zope.authentication too? No, I think they need to be just moved back into zope.password. The zope.authentication is expected to be tiny package that contains only interface definitions and PrincipalSource. - ILogoutSupported flag interface/adapter. Looks like it's only ever used for enabling/disabling the logout button in the UI. I'd deprecate it and leave in zope.app.security. That's an important feature. It could be really hard to nearly impossible to find out if an authentication provides logout or not without the ILogoutSupport adapter or a similar concept. We should think about how to replace that pattern if we skip the existing one. Okay then. The interface will be moved into zope.authentication as well. :-) Thanks for comment on that. -- 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: refactoring of zope.app.security
2009/3/11 Dan Korostelev nad...@gmail.com: Hi people! One of most large packages that really wants to be refactored but still wasn't touched is zope.app.security. It has much in it and it brings many dependencies, including zope.app.form and company. And even some zope.* packages, like zope.securitypolicy still depend on it. So, let's finally refactor it :) Here's a sketch of a refactoring plan I wrote after taking a quick look at the current package: - Move IAuthentication and other interfaces into new zope.authentication package. Also move there PrincipalSource and the checkPrincipal utility function. Also move there the PrincipalTerms class, however that will add dependency on zope.browser (which is really really tiny, as you may know). - Move global principal registry, its IPrincipal/IGroup implementations and its directives into new zope.principalregistry package. - Move LocalPermission into new zope.localpermission package. I personally didn't ever need local permissions. - Rewrite PermissionsVocabulary and PermissionIdsVocabulary not to depend on zope.app.component and move them into zope.security. It's generally useful there and won't introduce any new dependencies. - Move zcml definition of zope.Public permission. Maybe move security declaration for the `zope.security.permission.Permission` class as well. - Leave all browser views, globalmodules.zcml, _protections.zcml, other zope.* permission definitions in zope.app.security as well as backward-compatibility imports. - Just to note: the settings module was recently moved to zope.securitypolicy as there's the right place for it. Not sure about: - ILoginPassword and its basic implementations. The interface should probably go into zope.authentication while implementations - into zope.publisher. It will add a dependency on zope.authentication to zope.publisher, but the zope.authentication are expected to be really tiny and already installed for most applications, so I believe that it's okay. - PrincipalLogging - the adapter from zope.security.interfaces.IPrincipal to zope.publisher.interfaces.ILoggingInfo. I'd just move it into zope.publisher, because it's already tied to zope.security. - ILogoutSupported flag interface/adapter. Looks like it's only ever used for enabling/disabling the logout button in the UI. I'd deprecate it and leave in zope.app.security. - _protections.py module. It defines a NoProxy checker for zope.i18nmessageid.Message and adds __name__ and __parent__ attributes to _available_by_default. This module was executed in zope.app.security.__init__ and generally does useful things for most of applications. The problem is that neither zope.i18nmessage, nor zope.location already depend on zope.security. One solution is to move the protections in that packages, placing the code into try/except ImportError block to avoid hard dependency. Anyone? If there's no more opinions/objections/suggestions, I'd start refactoring. -- 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] z3c.form: nested group
2009/3/11 Laurent Mignon laurent.mig...@softwareag.com: Hi, 2 weeks ago, I've implemented a support for nested group into the branch svn://svn.zope.org/repos/main/z3c.form/branches/sagblmi-nestedgroup All test pass and no compatibility issue. Can I merge it to the trunk? I think yes, if you're sure that All test pass and no compatibility issue ;-) -- 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] zope.localpermission and the zope app permissions
Hi people! As a part of zope.app.security refactoring process, I extracted local (persistent) permissions to new zope.localpermission. And I faced one problem and I'm not sure about its resolution. Originally, I wanted to only move the zope.Public permission declaration into zope.security, because that permission name is special and always available. As for other permissions (zope.View/zope.Security/zope.ManageContent, etc.), I wanted to just leave them in zope.app.security as is. But security declarations for the LocalPermission class in zope.localpermission needs the zope.Security permission. Also, some of those permissions are used much in other zope.* packages for zcml security declarations. So, I wonder what should we do with this. One variant that seems nice to me is to create a package, called like zope.genericpermissions and place there the zcml file with permission definitions. I believe that not all permissions are used (for example, what's zope.ManageBindings?), so we could select only truly generic and needed permissions and leave the rest in zope.app.security. Opinions? Oh, and on the topic, one more time: can we have a steering group decision on the package requirements for zcml statements? Are we doing extras for them or simply skipping 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 )
Re: [Zope-dev] Proposal: refactoring of zope.app.security
2009/3/11 Martijn Faassen faas...@startifact.com: You should write up a short description of what zope.principalregistry does. In fact whenever we propose a new package we should describe its mission statement in just a couple of lines. That'll help us think about it better. I'll add a short README.txt to each package. The zope.principalregistry is an non-persistent implementation of IAuthentication that allows us to define principals via zcml (the principal directive and company) or with simple python calls. It's also quite useful for tests. I'm talking about local persistent permissions that can be added to ZODB and registered per site. It's zope.securitypolicy that gives local permissions, so, LocalPermission has nothing to do with local grants. Right, that's what I thought. Agreed they should go off into a package on its own, probably to eventually die. :) (I have bad memories of struggling with this stuff in a sprint in 2003). Yeah, that's a bit from TTW development that is not used much anymore, I want believe. ;-) - Move zcml definition of zope.Public permission. Maybe move security declaration for the `zope.security.permission.Permission` class as well. Move them where? Oh, that's a typo. Move them to zope.security. +1 The security declaration I assume can move without introducing dependencies on ZCML directives not in zope.security? I think we actually moved them in there during the sprint already, if I'm thinking about the right directives. Yeah, it's the class directive that was moved to zope.security on that sprint. Not sure about: - ILoginPassword and its basic implementations. The interface should probably go into zope.authentication while implementations - into zope.publisher. It will add a dependency on zope.authentication to zope.publisher, but the zope.authentication are expected to be really tiny and already installed for most applications, so I believe that it's okay. Why do you think the implementations of ILoginPassword should go into zope.publisher? Why not simply into zope.authentication? Because that implementations are zope.publisher specific, while zope.authentication as I see it could be used with any request objects and that way it could not depend on zope.publisher. It really seems odd we're suddenly introducing a new dependency for zope.publisher that wasn't there before. You'd think if that dependency isn't necessary now it shouldn't be necessary in the futur either. Could you delay this refactoring to later in the process at least and bring it up again separately when you get to it? Yep, I think that this refactoring will one of the last, so let's wait with that indeed. Anyway, how theoretical is it that zope.authentication could be used with any request objects? Does zope.authentication touch the request API in your mind at all? Refer to IBrowserRequest? No. The IAuthentication is meant to work with any request object, even not zope.publisher's one, like WebOb, or something. The only bits in current zope.app.security that is tied to zope.publisher is the implementations if ILoginPassword for zope.publisher's HTTP and FTP requests. BTW, the only thing that uses ILoginPassword is the global principal registry, but the interface is very useful in general. A short description of what zope.authentication is for would again be good, I think. It's basically the interface-only package that defines IAuthentication, PrincipalLookupError, IUnauthenticatedPrincipal, and so on, as well as little helper things, like the checkPrincipal function and the PrincipalSource/PrincipalTerms. It's intented to be used by any package that doesn't depend on particular authentication implementation, like zope.securitypolicy and others. To avoid overwhelming people with a huge amount of information in one mail, I suggest you post to the list for each step. I think this overview posting is good, and we should keep it up, but it's also hard to judge things individually and a lot to digest, so we should also discuss the steps (either before you do it if there are still uncertainties, or after you do it). Okay, I'll mail with a little description of work done for each step. I also would like you to write a couple of sentences describing zope.authentication, zope.principalregistry and any other new package you are thinking of creating. More or less something that could go into a README.txt in the introduction, or that could go into the description field in setup.py. Something sort so people know what these packages are for and can start reasoning about them. I described them above. But I'll remind about them in any mail that I'll post about this refactoring process. Also, when I'll be done, I'll write an general overview of new and changed packages (and after that we could also add it to 34to35.rst). -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http
Re: [Zope-dev] zope.localpermission and the zope app permissions
2009/3/11 Martijn Faassen faas...@startifact.com: Dan Korostelev wrote: Originally, I wanted to only move the zope.Public permission declaration into zope.security, because that permission name is special and always available. As for other permissions (zope.View/zope.Security/zope.ManageContent, etc.), I wanted to just leave them in zope.app.security as is. But security declarations for the LocalPermission class in zope.localpermission needs the zope.Security permission. Also, some of those permissions are used much in other zope.* packages for zcml security declarations. So, I wonder what should we do with this. If it doesn't introduce new dependencies, I think a few more definitions of permissions in zope.security won't hurt (only those commonly used). I'd like that better than introducing a new package. Do you think this will be tolerable to you? I also thought about this, but I decided that people will be against that, because zope.security is intended to be really generic and only permission it defines is the special zope.Public (there even was discussions about renaming it to plain public). However, it's fine with me, as long as we define them in a separate zcml file that can be excluded and/or redefined for some special case. We should indeed only move those widely used. That will require some research. When I'll be doing that, I'll post my opinion on what permissions should go to standard ones and what to deprecate and will call for comments and more information. The problem we have is that some content objects (i.e. not only the ZMI) declare that some of their methods need permissions. In order to support those we do need to have the definitions in a central place, and I think zope.security would be as good as any if we can do it without introducing more dependencies. Just put them in a separate submodule and we should be okay. Yup, fine then. However, I think that there's no need for a submodule when we can do that in simple separate zcml file. Or I miss something? -- 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] Dependencies for ZCML
2009/3/11 Martijn Faassen faas...@startifact.com: Oh, and on the topic, one more time: can we have a steering group decision on the package requirements for zcml statements? Are we doing extras for them or simply skipping them? Sorry, I wasn't clear that there was an open question and I'm afraid I don't understand this one. :) Could you point me to the appropriate thread that was left in the middle, or could you start a new thread with a description of the open question? I'm too lazy now to search in archives, so I'll just describe again. For example, the zope.password package only requires zope.interface to be functional. But it's configure.zcml contains directives that need zope.component (or repoze.zcml) and zope.security. Also, the zcml thing itself needs zope.configure as well. Should we mention it in extra dependencies somehow or just document it, saying that zcml is intented to be used in more zope3-ish environment that already has needed packages, so others can simply ignore these files. -- 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: refactoring of zope.app.security
2009/3/12 Benji York be...@zope.com: On Wed, Mar 11, 2009 at 1:52 PM, Dan Korostelev nad...@gmail.com wrote: 2009/3/11 Martijn Faassen faas...@startifact.com: You should write up a short description of what zope.principalregistry does. In fact whenever we propose a new package we should describe its mission statement in just a couple of lines. That'll help us think about it better. I'll add a short README.txt to each package. The zope.principalregistry is an non-persistent implementation of IAuthentication that allows us to define principals via zcml (the principal directive and company) or with simple python calls. It's also quite useful for tests. bikeshed Maybe we can use the description or long_description field in the setup.py for the package mission statement /bikeshed Of course there will be description and long_description. Moreover, the long_description in most cases will start with contents of the README.txt, like it's done in most of packages already. :) -- 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] Proposal: move zope.site.next functions to zope.component.
Hey, people! While working on splitting authentication interfaces and PrincipalSource from zope.app.security to new zope.authentication package, I discovered that PrincipalSource uses some functions from zope.site, which is unacceptable dependency. Those functions are getNextUtility and queryNextUtility and they are all that is contained in the zope.site.next module. What they do is looking up an utility in the __bases__ of given component registry, so returning a higher level utility. That functionality doesn't depend in any way on persistency or locatability of component registries and can be very useful with plain zope.component's registries. Moreover, it does use an implementation detail of zope.component.registry.Components class - the __bases__ attribute. :-) So, I propose to move this tiny (see for yourself) functionality to the zope.component package, so code that needs it wouldn't depend on zope.site. If there won't be any objections, I'll do that. -- 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] Release of zope.component (was [Checkins] SVN: zope.component/trunk/ Merge the 'tseaver-wo_zope_deferredimport' branch)
I decided to start a new branch of that, because there's no still response on my requests for a release. Here's the last message: Let's decide that and make a release of zope.component so we could move forward on adapting other packages to recent removal of BBB interfaces. Here's three variants: * Move pure python implementation to zope.hookable as a fallback. * Move C implementation to zope.component and drop zope.hookable dependency at all. * Just drop zope.hookable dependency, providing only pure python version of hookable. The second (or even third, if there's no significant slowdown) variant seems fine to me personally, because, as Tres noted, there's probably no consumers for zope.hookable beyond zope.component, so we can safely merge the packages. Jim, Philipp, Marius, can you please give us rights on PYPI for zope.component. My account is nadako there, so you can give it to me and I'll add other people. -- 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] New package: zope.authentication AND the problem.
Hey, community. As a part of zope.app.security refactoring process, a new package has been created - zope.authentication. It basically contains IAuthentication and other auth-related interfaces, as well as PrincipalSource. So it's intended to define a basic concepts and contracts of principal authentication for the zope framework to be implemented by other packages. There are three implementations that I know of currently: the global principal registry from zope.app.security (it will be moved into new package, called zope.principalregistry), the zope.app.authentication and z3c.authenticator. It's quite request type independent so it can be used with non-zope.publisher requests, like WebOb or something, but here the problem appears: The zope.app.security defines the ILoginPassword (getLogin,getPassword,needLogin) adapters for zope.publisher's HTTP and FTP requests. I wonder where should they go, because the zope.authentication package doesn't want to depend on zope.publisher, as (like i said before) it is intended to be tiny and independent on any request implemenation. I'd move those adapters into zope.publisher itself, but this will require adding the zope.authentication dependency for zope.publisher, which I think is okay, because zope.authentication is very small and will probably be used together with zope.publisher anyway. Another solution which I like much less is to move those adapters to zope.authentication and define an extra dependency (sigh) on zope.publisher, but then the package won't be so nice, clean and generic as it could be. :-) Opinions? -- 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] Common permissions (final bits of zope.app.security refactoring)
Hey, people! The refactoring of zope.app.security is now almost done. There's still some polishing work to do and two little issues to resolve. One of them is the zope's common permissions. Most of zope.* and zope.app.* (and other) packages define some security protections for their classes and views using common permission names defined in zope.app.security. We decided to move those permission definitions to a separate and excludable/overridable zcml file to zope.security, so packages that use them would't need to install anything additional. But we want only generic and useful permissions to be a part of common set, so we need to select ones from zope.app.security. Currently, zope.app.security defines these permissions (not counting zope.Public, that already migrated to zope.security): - zope.View - zope.Security - zope.ManageContent - zope.ManageBindings - zope.ManageCode - zope.ManageServices - zope.ManageSite - zope.ManagePrincipals - zope.ManageApplication Permissions, that needs to be in a common set (IMHO), mostly because it's used by current zope.* packages: - zope.View - zope.ManageContent - zope.Security - zope.ManageServices - zope.ManageSite To be honest, I don't quite get the difference between zope.ManageSite and zope.ManageServices. Can someone clear this point for me? May be they should be merged somehow. Permissions that can stay in zope.app.security, and reasons: - zope.ManageBindings - What's that? I can't find any usage of it. - zope.ManagePrincipals - That looks like it was intended for something like zope.app.authentication, but zope.ManageServices is used there instead. - zope.ManageCode - I guess it's intended for TTW development that's not used/developed much and even discouraged now-a-days? If so, I believe that it can stay in zope.app.security. - zope.ManageApplication - Looks like it's intended for and used mostly in zope.app.applicationcontrol which has more to do with zope3, the application server, than the zope.framework. -- 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] zope.password
2009/3/10 Roger Ineichen d...@projekt01.ch: Hi steering group and Dan During update z3c.authenticator and replace the password with the new zope.apssword implementation, I saw that the vocabulary Passsword Manager Names is not available in the zope.password package. I think the password package should also provide this vocabulary. Or at least the zope.app.authentication package should not configure that. Do you see any solution to solve that problem that not both package zope.app.authentication and z3c.authenticator configure that utility within the same name (needs the exclude directive for make that working) This was done to avoid dependency on zope.schema. However, I also find it very useful to have that vocabulary in zope.password. I think we can add it to the vocabulary submodule without adding dependency on zope.schema at egg level, because one who wants to use the vocabulary probably already has zope.schema installed. I'll do that. -- 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] Python3 and attribute annotations.
2009/3/10 Martijn Pieters m...@zopatista.com: On Mon, Mar 9, 2009 at 23:35, Dan Korostelev nad...@gmail.com wrote: However, we can't be sure there won't be annotations for any callable object, because even PEP says that ``we say function, we mean callable object``, so one day we certainly will conflict with something. Also, as Gary pointed out, we mis-use the __*__ name pattern that is now intended for defining special names that have special meaning for python interpreter. And we'll certainly will mis-use the __annotations__ name as it's clearly defined in python 3k. So, after Gary reminded about __*__ names, I think we shoud use something like _z_annotations. Semi-agreed. Tools that access ZODB objects and expect __annotations__ to follow the PEP 3107 conventions will be quite surprised. I doubt that there will be many tools to do so though. Well, with ZODB, that tools don't need to know that objects are from ZODB. To them they are simple Python objects and they expect compatible behaviour. Then again, if Python is now explicitly claiming the __*__ naming convention, Zope better avoid it's usage. This means we'll have to fix __parent__ and __name__ usage as well. This will be painful, me thinks.. Yep, this will be the pain for sure. However, __parent__ and __name__, and even __bases__ for component registries should be fine for now (however we should think about moving them as well). But with __annotations__ I expect much confusion and problems. -- 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] zope.password
2009/3/10 Hanno Schlichting hanno...@hannosch.eu: Dan Korostelev wrote: This was done to avoid dependency on zope.schema. However, I also find it very useful to have that vocabulary in zope.password. I think we can add it to the vocabulary submodule without adding dependency on zope.schema at egg level, because one who wants to use the vocabulary probably already has zope.schema installed. I'll do that. That reasoning sounds flawed to me. Either you have a dependency and declare it or you don't have a dependency. Since we don't want to use extras anymore, I think this calls for another package which depends on zope.password and zope.schema. I still don't like/get the idea of creating and maintaining extra package that merely contains a vocabulary factory for another package. Whatever, I reverted that change. Roger, just exclude zope.app.authentication's password.zcml file, include zope.password explicitly and define your own vocabulary. -- 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] zope.password
2009/3/10 Roger Ineichen d...@projekt01.ch: Hi Steering group, Hanno, Dan Betreff: Re: [Zope-dev] zope.password Dan Korostelev wrote: 2009/3/10 Hanno Schlichting hanno...@hannosch.eu: Either you have a dependency and declare it or you don't have a dependency. Since we don't want to use extras anymore, I think this calls for another package which depends on zope.password and zope.schema. I still don't like/get the idea of creating and maintaining extra package that merely contains a vocabulary factory for another package. Whatever, I reverted that change. Roger, just exclude zope.app.authentication's password.zcml file, include zope.password explicitly and define your own vocabulary. I don't quite like the idea of extras and we decided to avoid them. We also decided to avoid tests_require from what I understand. What you did was to not specify an extra nor a hard dependency, but still add zope.schema to the test extra section. That feels wrong. Either you have a dependency and so have the tests or you don't. I think extras have been created for this kind of use-case of providing an optional feature from a package. Either we use that mechanism and declare it, or we don't want this mechanism and live with creating extra packages instead. Hanno, Can you propose something else to solve our problem? The problem is, zope.password offers password manager which get used by zope.app.testing, zope.app.authentication, z3c.authenticator and other packages. zope.app.authentication configures the vocabulary for the password managers in zope.password. That's defently a no go. Write another package for just define and register them is I think also a no go. Probably we should depend zope.password on zope.schema too and configure the vocabulary and managers registry there. Dan, I think we should not be to excessive with the dependency cleanup and stop ourself. It would be nice to use zope.password without the zope.schema package but that's right now no use case for our refactoring. I'd like to be able to use zope.password without zope.component for some of my tiny old Pylons-based projects, that's why I'm trying to avoid dependency on it. I believe that repoze guys will also be quite happy, if it didn't pull unneeded (for them) dependency. I'd be fine with an extra requirement, but others seem to be against that. :-/ Steering group? ;-) -- 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] Proposal: refactoring of zope.app.security
Hi people! One of most large packages that really wants to be refactored but still wasn't touched is zope.app.security. It has much in it and it brings many dependencies, including zope.app.form and company. And even some zope.* packages, like zope.securitypolicy still depend on it. So, let's finally refactor it :) Here's a sketch of a refactoring plan I wrote after taking a quick look at the current package: - Move IAuthentication and other interfaces into new zope.authentication package. Also move there PrincipalSource and the checkPrincipal utility function. Also move there the PrincipalTerms class, however that will add dependency on zope.browser (which is really really tiny, as you may know). - Move global principal registry, its IPrincipal/IGroup implementations and its directives into new zope.principalregistry package. - Move LocalPermission into new zope.localpermission package. I personally didn't ever need local permissions. - Rewrite PermissionsVocabulary and PermissionIdsVocabulary not to depend on zope.app.component and move them into zope.security. It's generally useful there and won't introduce any new dependencies. - Move zcml definition of zope.Public permission. Maybe move security declaration for the `zope.security.permission.Permission` class as well. - Leave all browser views, globalmodules.zcml, _protections.zcml, other zope.* permission definitions in zope.app.security as well as backward-compatibility imports. - Just to note: the settings module was recently moved to zope.securitypolicy as there's the right place for it. Not sure about: - ILoginPassword and its basic implementations. The interface should probably go into zope.authentication while implementations - into zope.publisher. It will add a dependency on zope.authentication to zope.publisher, but the zope.authentication are expected to be really tiny and already installed for most applications, so I believe that it's okay. - PrincipalLogging - the adapter from zope.security.interfaces.IPrincipal to zope.publisher.interfaces.ILoggingInfo. I'd just move it into zope.publisher, because it's already tied to zope.security. - ILogoutSupported flag interface/adapter. Looks like it's only ever used for enabling/disabling the logout button in the UI. I'd deprecate it and leave in zope.app.security. - _protections.py module. It defines a NoProxy checker for zope.i18nmessageid.Message and adds __name__ and __parent__ attributes to _available_by_default. This module was executed in zope.app.security.__init__ and generally does useful things for most of applications. The problem is that neither zope.i18nmessage, nor zope.location already depend on zope.security. One solution is to move the protections in that packages, placing the code into try/except ImportError block to avoid hard dependency. -- 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] Question: additional context for IAnnotations adapter?
2009/3/9 Dieter Maurer die...@handshake.de: Jacob Holm wrote at 2009-3-6 01:55 +0100: ... I added it while working for ZC two years ago. It was needed to support a use case where the context used for looking up the annotation was not necessarily the current site. I don't know if the use case is still relevant to ZC, but the pattern is still being used in e.g. zc.notification and zope.app.preference (where it was added by me at the time). I expect that use cases like this (looking up objects in a foreign site context) will be important for my current employer (if it continuous to use Zope in the future). Thanks for comments. The functionality stayed and migrated to zope.principalannotation. It now even have a doctest. :-) -- 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] Python3 and attribute annotations.
Hi zope developers! As you may know, python 3 introduced the concept of annotations for callable objects. That annotations store information about arguments and return values, which is kinda nice language feature that will allow us to do interesting things. But there's a problem: those annotations will be stored in object's __annotations__ attribute, which is also used by zope.annotation's AttributeAnnotation implementation, so they will conflict. I think that it's a good time now to start thinking about problems like this, because there's a lot of time before zope will be used in python 3.0, so we can prepare to move without much problems. So, I propose to change annotation storage attribute to __zope_annotation__ and make AttributeAnnotation adapter automatically migrate data from __annotations__ to __zope_annotations__. I think that adding zope to the attribute name will avoid any name clashes in future. I'd like to hear about problems that this change can possibly introduce (__slots__, security proxies, etc.) and maybe some more community ideas on that. -- 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] SVN: zope.component/trunk/ Merge the 'tseaver-wo_zope_deferredimport' branch:
2009/3/5 Martijn Faassen faas...@startifact.com: Chris Withers wrote: Martijn Faassen wrote: I think we can only make the correct determination if we get an idea of the performance implications. If it turns out the C code brings significant speedups in real-world applications, we should create a zope.hookable with a Python + C implementation. Even if it does bring significant speedups, why does it need to be a seperate package? It doesn't, but it's already a package that could be easily turned into something with proper documentation (it's mostly there, just hidden), and one of the goals was to reduce C dependencies in zope.component, not add C code to it. Let's decide that and make a release of zope.component so we could move forward on adapting other packages to recent removal of BBB interfaces. Here's three variants: * Move pure python implementation to zope.hookable as a fallback. * Move C implementation to zope.component and drop zope.hookable dependency at all. * Just drop zope.hookable dependency, providing only pure python version of hookable. The second (or even third, if there's no significant slowdown) variant seems fine to me personally, because, as Tres noted, there's probably no consumers for zope.hookable beyond zope.component, so we can safely merge the packages. Jim, Philipp, Marius, can you please give us rights on PYPI for zope.component. My account is nadako there, so you can give it to me and I'll add other people. -- 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] choice of test runner...
2009/3/8 Chris Withers ch...@simplistix.co.uk: Wichert Akkerman wrote: I would like to see a move away from zope testing frameworks to a more standard testing infrastructure: setup.py test, possibly combined with using nose. I'd love to see a side-by-side feature comparison of the major python test discovering and runner frameworks. It would then be interesting to see if there's a compelling enough reason for The Zope Framework steering committee to make a pronouncement on which one to use... +1 -- 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] [Checkins] SVN: zope.file/trunk/ Update package mailing list address. Remove zpkg stuff.
2009/3/5 Benji York be...@zope.com: On Wed, Mar 4, 2009 at 6:36 PM, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Baiju M wrote: On Tue, Mar 3, 2009 at 2:35 PM, Dan Korostelev nad...@gmail.com wrote: 2009/3/2 Tres Seaver tsea...@palladion.com: -include package=zope.file/ I believe people still use the ZCML slug files like the above. They certainly aren't related to 'zpkg'. The intent of the slugs was to allow for something like 'sites-available' / 'sites-enabled' (the pattern in a stock Debian Apache2 install). I think it is particularly unfortunate to remove support for explicit, granular configuration at the same time as folks seem to be jumping to implicit (aka majyk) tools. Please revert this part of the change. I just reverted the change, however, I don't think that the slug files are useful anymore. I cannot see similar slugs in other packages either. Agreed. I don't understand Tres's or Benji's point either; thanks to buildout we've left such slugs long behind us I thought. Typically people would symlink these into an old old installation of Zope 3 (or copy them over). Explicit granular configuration isn't broken at all; if you want to explicitly include zope.file, you include its configure.zcml, not its zope.file-configure.zcml. Unless Tres comes back with some convincing explanation soon, please do get rid of this stuff. Those files exist to allow for a use case we may have abandoned, which is allowing packages to be installed in such a way that a tool could help users enable / disable their configurations, without mutating something like 'site.zcml'. The folks who might have that usecase are those who package zope3 components for deployment outside buildout (as .deb / .rpm, etc.) I don't know if there is such an audience; Benji also pointed out that he thought there were such folks. I don't doubt there are still at least a few, but I also don't think we are supporting that use case very well moving forward. We just need to make an explicit decision to drop support, and then we can remove the slug files. Can we have an official desicion from The Steering Group on that? My initial reaction to Dan's removal was that the checkin message (remove zpkg stuff) had nothing to do with that particular change: 'zpkg' was entirely separate from slugs. Same here. Well, I simply didn't mention the removal of zcml slug, I know that it's not related to zpkg. -- 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] zope.publisher uses deprecated IView
2009/3/6 Tres Seaver tsea...@palladion.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hey, Wolfgang Schnerring wrote: since Dan Korostelev commented on my https://bugs.launchpad.net/zope3/+bug/338136 saying I should take it to the mailing list, here goes: zope.publisher.interfaces.browser.IBrowserView inherits from zope.component.interfaces.IView, which actually is zope.component.bbb.interfaces.IView -- marked as deprecated since 2004, but no pointer what the replacement should be. What's going on here? I actually remember running into this many many years ago and got so confused I gave up on it then. :) Hopefully someone else can tell you more! Something is definitely funky in here. I wonder what happens to our compattests if we simply remove this inheritance relationship. If nothing directly refers to IView it might mean everything will still work... I just undeprecated IView and the other 'bbb' interfaces for exactly this reason: if core packages still use them five years later, then the deprecation loses. I doubt that the IView and (especially) IPresentation/IContextDependent are actually imported/used anywhere directly. Especially when they were deprecated for years. So I'm +10 on simply removing the inheritance and that BBB interfaces themselves, as they only create confusion when someone tries to find out what those interfaces constist of. As for others, I bet IResource could be safely moved into zope.app.publisher and the IDefaultViewName - to zope.publisher to make company for IDefaultSkin. :) As for IViewFactory/IResourceFactory - they are not used by zope. For example, the BrowserView and BrowserPage classes don't provide those interfaces. So I propose to simply remove 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 )
Re: [Zope-dev] setup.py extra dependencies
2009/3/6 Tres Seaver tsea...@palladion.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hey, Laurence Rowe wrote: [snip] It seems there is a 'tests_require' One reason that isn't used is that apparently there is no way for us to dig up this information in the way our test runner needs, unlike extras requires. If the testrunner would require 'eggtestinfo', and introspect the extra data it records, this wouldn't be true any longer. +1. Though, if that eggtestinfo package is really tiny, as I believe it is, we could just copy it into the testrunner not to create extra dependencies. -- 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] Proposals: more refactoring
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 ___ 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] Proposals: more refactoring
2009/3/5 Dan Korostelev nad...@gmail.com: 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? Ah, I forgot that the password managers are intended to be registered and used as named utilities, so I guess zope.component and zope.schema dependencies are okay. Though, we could move that deps in the extra. -- 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] setup.py extra dependencies
2009/3/5 Martijn Faassen faas...@startifact.com: Hi there, I know opinions are divergent about 'extra' dependencies in setup.py. These ar dependencies that effectively make a single project with a single dependency structure into a number of virtual packages that each can have a separate list of dependencies. Such a virtual package that we're currently getting rid of is zope.component[zcml]. I think they make the graph harder to reason about. That's bad, we want to reason about the system more easily. So I propose that: * we shouldn't create any new extra dependencies from now on. * we should investigate ways to remove the need for 'extra' dependencies. The latter point would of course not be done instantly, but if we agree we don't want to create *more* extra dependencies we can agree on starting with that policy right away. One place where extra dependencies are used quite a lot is in testing. One extra dependency that shows up a lot is a dependency on zope.app.testing. I think that *also* makes things much harder to reason about; testing dependencies should follow normal package dependencies. I therefore think zope.app.testing is one package we should be looking to get rid of eventually by splitting it up among a lot of 'testing' modules in individual packages. This way we won't have zope.app.testing sitting at an edge against our whole dependency tree. Since this is a lot of work this will be an ongoing project but we could at least agree we *want* to do this. Opinions? + for removing test extras. -0.75 for removing functionality extras. I still don't get how extras are different from additional packages. I'd also like to officially clear things about dependencies for zcml configuration. Most of our packages can be used nicely without any zcml, but the zcml-related dependencies can be quite large. I think that the extras here will do a nice job. I mailed about that a while ago. -- 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] Question: additional context for IAnnotations adapter?
Hi there! While looking at the zope.app.principalannotation package, I discovered that both zope.annotation and zope.app.principalannotation register their IAnnotations adapters twice: fisrt, as a simple adapter and second, as a multi adapter for some additional context object. The zope.annotation doesn't use that additional context at all - it just allows to get annnotations by multi-adapter lookup. The zope.app.principalannotation uses the additional context object as context argument for getSiteManager, which I believe is not needed and/or used in most cases, because application components, like zope.site provide their hooks to get the right site manager. There's no documentation or any tests for that behaviour neither in zope.app.principalannotation, nor in zope.annotation, so I made an assumption that these registrations are there just to support some very old annotation pattern, that was deprecated ages ago. If it's like that, I'd like to remove that registration for zope.principalannotation that is about to born as well as for zope.annotation. Can someone clarify this point? -- 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] setup.py extra dependencies
2009/3/5 Gary Poster gary.pos...@gmail.com: On Mar 5, 2009, at 1:43 PM, Martijn Faassen wrote: Hi there, I know opinions are divergent about 'extra' dependencies in setup.py. These ar dependencies that effectively make a single project with a single dependency structure into a number of virtual packages that each can have a separate list of dependencies. Such a virtual package that we're currently getting rid of is zope.component[zcml]. ... Opinions? I disagree with the blanket statement. I do lean towards not having the extras for the test package only. I'm fine with the policy If you want zope.testing for your tests, then keep it as a dependency for the package. But I like to have the option of extras for testing additional setups. zc.async uses extras so that the main tests show the functionality as a Python library; another level adds more Zope dependencies, with associated tests; and the last level adds the most. I could have divided these up into multiple teensy-weensy packages but I didn't really want to. It seemed like overkill. I've also done this in other circumstances in which code could use zope.proxy/zope.security, but I really didn't want to add the hard dependency. The tests to show that proxies were handled correctly were only part of the extras. Dividing this package also would have made no sense--it was already just a few small classes. For a package as central as zope.component, I think the pattern Tres is pursuing--dividing everything up--makes sense. For most other packages, I personally feel that there are circumstances in which extras are a useful tool. A strong +1 on that explanation. -- 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] zope3docs - zopeframework?
2009/3/4 Martijn Faassen faas...@startifact.com: 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? Well, that docs are currently not necessarily about the zope framework (as far as I understood what's zope framework now), but more about general development guidelines applied to any package in zope svn (except the migration section, maybe), but I personally don't have any objections, as it's still easy to find those docs and that's the most important. :-) -- 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] [Checkins] SVN: zope.file/trunk/ Update package mailing list address. Remove zpkg stuff.
2009/3/2 Tres Seaver tsea...@palladion.com: -include package=zope.file/ I believe people still use the ZCML slug files like the above. They certainly aren't related to 'zpkg'. The intent of the slugs was to allow for something like 'sites-available' / 'sites-enabled' (the pattern in a stock Debian Apache2 install). I think it is particularly unfortunate to remove support for explicit, granular configuration at the same time as folks seem to be jumping to implicit (aka majyk) tools. Please revert this part of the change. I just reverted the change, however, I don't think that the slug files are useful anymore. They were used when we had the zope3 application server and we plugged some components into it, like sites are plugged into debian apache/nginx setups, but now-a-days, when it seems that most people just build their own applications using their custom app configuration files, I don't think that there's much sense for package-includes for including components like zope.file. I can think of a use for package-includes for some CMS application that include website configuration (like debian apache), but not the component configuration. -- 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] [Checkins] SVN: zope.component/branches/tseaver-wo_zope_deferred/ Branch removing zope.deferred.
2009/3/4 Tres Seaver tsea...@palladion.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan Korostelev wrote: 2009/3/4 Tres Seaver tsea...@palladion.com: Log message for revision 97465: Branch removing zope.deferred. Changed: D zope.component/branches/tseaver-wo_zope_deferred/src/zope/component/bbb/ -# BBB: Backward-compatibility; 12/05/2004 -from bbb.interfaces import * Note, that the context-dependent/presentation/view stuff that was in BBB interfaces are still used in some places, like zope.publisher, so this needs more careful (re)moving. I think that one of the nice places for those interfaces is zope.browser, however they are not necessary browser-related, so maybe they should be moved elsewhere or just placed in zope.component.interfaces for now, as they're really tiny. Yup. That was probably a case of premature deprecation (back in 2004). Note that I'm not actually proposing that we merge this branch any time soon: it is a bit of a straw man for the ongoing process conversation. Why not? It looks that it's just a dependency cleanup, so it can be merged (and released!) really soon (if noone objects, of course). I personally don't like long-living branches and forks. -- 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] [Checkins] SVN: zope.component/branches/tseaver-wo_zope_deferred/ Branch removing zope.deferred.
2009/3/4 Tres Seaver tsea...@palladion.com: Note that I'm not actually proposing that we merge this branch any time soon: it is a bit of a straw man for the ongoing process conversation. Why not? It looks that it's just a dependency cleanup, so it can be merged (and released!) really soon (if noone objects, of course). I personally don't like long-living branches and forks. Well, part of the dependency cleanup involves making a possibly- controversial coding style change (from imports), Will it cause any problems in packages that use existing zope.component with its current coding style? If not, then why can it be a problem? and I may have broken something in the 'compattests'. Well, that certainly needs to be tested, but I don't think it's a blocker for merging. We're on the development version anyway. :-) (however, of course if would be nicer to do compattests before merging, but this should'nt take much time?) I would also like to make 'setup.py test' actually work in the absence of buildout. Isn't this as easy as adding the contents of test extra to the test_requires parameter? -- 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] [Checkins] SVN: zope.i18n/trunk/ Merge the nadako-sorting branch, updating CLDR to 1.1.
2009/2/27 Stephan Richter srich...@cosmos.phy.tufts.edu: On Friday 27 February 2009, Dan Korostelev wrote: Also, I it looks crazy how zope.i18n.locales things works, especially when it comes to inheritance. :) Feel free to improve it. :-) Well, it's quite hard when it comes to backward-compatibility, but I'll certainly think on some ways to improve. Instead of implementing inheritance I would now just allow copying a locale and merge new data on top of it. Nobody changes locales on the fly anyways, so the entire inheritance mechanism is superfluous. Yeah, I also think so. BTW, Babel does that exactly. Also, newer LDML support more complex locale inheritance schemas that will be harder to integrate into current locale mechanism. :-/ I even have some thoughts about just integrating Babel into zope.i18n, as it does CLDR much better. Can you give me a link? Sure. http://babel.edgewall.org/ Looks very good. We probably should switch to them. We can even provide some tests to their project. I'd support switching to Babel. If noone objects, I'll try to do that in my branch. -- 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] Proposal: merge zc.configuration's exclude directive into zope.configuration.
Hi there. The exclude directive provided by zc.configuration package is easy to use and straightforward. I think it's used almost in every zope-based application setup. Its implementation is very small and fits great in zope.configuration's standard directives. So I'd like to propose to move it to zope.configuration and make it always available for ZMCL files, just like the include directive, so people would'nt need to install extra package and include an extra meta.zcml file before being able to use it. If noone objects, I'd like to do that and make the exclude directive from zc.configuration point to the zope.configuration's implementation making the original place deprecated (however I guess the whole zc.configuration package should't be deprecated as it's intended to be a common place for configuration extensions, even if it has only one directive now). Jim, if you're fine with that, can you please give me rights for zc.configuration on PYPI, my user name is nadako. -- 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: merge zc.configuration's exclude directive into zope.configuration.
2009/2/26 Martijn Faassen faas...@startifact.com: Dan Korostelev wrote: The exclude directive provided by zc.configuration package is easy to use and straightforward. I think it's used almost in every zope-based application setup. I highly doubt so; I don't find myself using it a lot myself, for instance. :) Well, may be, really not in every app, but it's still used alot. :-) (note though that including an extra meta.zcml can be avoided if you make use of the z3c.autoinclude library) Yep, I know about z3c.autoinclude, but I don't like it, as it makes things more implicit and it also slows down startup time for applications that uses many eggs. I'd like to see an option for packages that are using z3c.autoinclude to make autoincluding conditional, so those who doesn't like it or needs more control could just turn it off. -- 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: merge zc.configuration's exclude directiveinto zope.configuration.
2009/2/26 Roger Ineichen d...@projekt01.ch: (note though that including an extra meta.zcml can be avoided if you make use of the z3c.autoinclude library) Oh, cool. Now we only need to find out how to write an z3c.autoexlude and a z3c.autooverride library ;-) :-)) +1 -- 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: merge zc.configuration's exclude directive into zope.configuration.
2009/2/26 Jim Fulton j...@zope.com: and make the exclude directive from zc.configuration point to the zope.configuration's implementation making the original place deprecated (however I guess the whole zc.configuration package should't be deprecated as it's intended to be a common place for configuration extensions, even if it has only one directive now). Jim, if you're fine with that, can you please give me rights for zc.configuration on PYPI, my user name is nadako. Done, although, if you were me, you'd just leave it. :) Thanks. I think we need to make people know that they don't need this package anymore if they are looking for a way to exclude configuration. -- 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] [Checkins] SVN: z3c.pagelet/trunk/src/z3c/pagelet/tests.py Reenable z3c.pt tests, breaking tests again.
Can someone who is familiar with z3c.pt check this out, please? It
looks like the z3c.pt.expressions.ContentProviderTraverser somehow
receives wrong context/request/view objects.
Also, the ContentProviderTraverser should fire the BeforeUpdateEvent
before updating the content provider. And what about ITALNamespaceData
support? The contentprovider support won't be full without these
things.
2009/2/26 Dan Korostelev nad...@gmail.com:
Log message for revision 97320:
Reenable z3c.pt tests, breaking tests again.
Changed:
U z3c.pagelet/trunk/src/z3c/pagelet/tests.py
-=-
Modified: z3c.pagelet/trunk/src/z3c/pagelet/tests.py
===
--- z3c.pagelet/trunk/src/z3c/pagelet/tests.py 2009-02-26 16:54:30 UTC (rev
97319)
+++ z3c.pagelet/trunk/src/z3c/pagelet/tests.py 2009-02-26 17:02:59 UTC (rev
97320)
@@ -94,9 +94,7 @@
),
DocFileSuite('zcml.txt', setUp=setUp, tearDown=tearDown,
optionflags=doctest.NORMALIZE_WHITESPACE|doctest.ELLIPSIS,),
- ) for setUp in (setUpZPT, ))
- #) for setUp in (setUpZPT, setUpZ3CPT, ))
- # XXX: z3c.pt's provider expression is currently broken
+ ) for setUp in (setUpZPT, setUpZ3CPT, ))
return unittest.TestSuite(itertools.chain(*tests))
--
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] Zope.pipeline proposal
2009/2/25 Martijn Faassen faas...@startifact.com: One area that I'd like to see support for is some easy way to turn off security proxies. It's rumored there is such a way but with Grok, we ended up ripping them off repeatedly anyway. Am I right in that it should be possible to put a WSGI endware on top of this whole stack that does an explicit security check? I think so. Currently, the main entry point for security proxies is the get root method of the publication, so if you'll use modified publication object that don't wrap root object in the ProxyFactory, you'll rip most of them. However, some things, like trusted adapters rewrap objects using ProxyFactory, so, maybe we could add some modifier to the ProxyFactory function that just makes it return object as is w/o wrapping. This way we could turn off proxies globally without need to modify code that uses ProxyFactory. -- 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] [Checkins] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
Wow, that's great! Finally an OpenID auth plugin is being developed! plone.openid has been out since August 2007, so it's hardly the first OpenID auth implementation for Zope.. Well, yeah, but plone.openid uses Zope2 and Plone PAS while this is a pure zope3 solution. However I'd like to see parts that are neither zmi-specific nor plone-specific to be refactored to a separate package. The ZopeStore from plone.openid, for example :-) -- 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] [Checkins] SVN: z3c.mimetype/ Create infrastructure for z3c.mimetype
2009/2/24 Benji York be...@zope.com:
On Tue, Feb 24, 2009 at 8:29 AM, Dan Korostelev nad...@gmail.com wrote:
2009/2/24 Baiju M mba...@zeomega.net:
Hi Dan,
On Tue, Feb 24, 2009 at 6:40 PM, Dan Korostelev nad...@gmail.com wrote:
Log message for revision 97207:
Create infrastructure for z3c.mimetype
Changed:
A z3c.mimetype/
I thought of sharing this with you, may be useful. I have got one tip from
Jim for creating a new project area:
http://mail.zope.org/pipermail/zope3-dev/2006-October/020701.html
Heh, nice trick with `z` :) Thank you.
A slight refinement:
svn mkdir path-to-repo/new-project{,trunk,tags,branches}
Using the `z` trick, that would be:
svn mkdir `z`/new-project{,trunk,tags,branches}
Thanks! BTW, there tips are probably useful enough to be included to
zope3docs' development section. :)
--
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] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
2009/2/24 Jim Fulton j...@zope.com: I agree that it shouldn't go in zope.app. I believe I suggested putting this in zc.openid, although I'm fine with zope.openid. Why zc? I thought it's only for packages coming from the zope corporation. Or does Shane works for ZC? :) -- 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] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
2009/2/24 Shane Hathaway sh...@hathawaymix.org: Dan Korostelev wrote: 2009/2/24 Jim Fulton j...@zope.com: I agree that it shouldn't go in zope.app. I believe I suggested putting this in zc.openid, although I'm fine with zope.openid. Why zc? I thought it's only for packages coming from the zope corporation. Or does Shane works for ZC? :) This is for a ZC contract. Ah, then zc namespace if fine of course! :) -- 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] Consensus on the ZMI and zope.app.* namespace. (Was: SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3)
2009/2/25 Martijn Faassen faas...@startifact.com: I hope in fact zope.app.* will soon become a dumping ground for deprecated packages providing legacy ZMI support. Of course that will need the consensus that the ZMI *is* legacy software. I think do we already have a consensus that packages that provide other useful functionality shouldn't be providing ZMI support within the same package. Though it's a very big +1 from me that packages providing useful functionality shouldn't contain ZMI-related stuff within the same package, and that's our goal, I wouldn't say that ZMI is a legacy software, as it's very useful out of box and can be easily extended to make real use of Zope. I'd rather say that ZMI is an example of extensible application built on top of zope frameworks and it should be positioned like that. BTW, I have a thought about an additional refactoring strategy: we could move ZMI-related packages to separate packages, like zmi.* or something, leaving imports in zope.app.* and making zope.app.* really deprecated. That way we can state that ZMI is not the Zope, but something built on it. And this way gives us more refactoring freedom :) Any thoughts? -- 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] [Checkins] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
2009/2/24 Shane Hathaway sh...@hathawaymix.org: Log message for revision 97183: New library for OpenID auth in Zope 3 Changed: A zope.app.openidconsumer/ Wow, that's great! Finally an OpenID auth plugin is being developed! Thank you :) I thought about publishing this myself many times, but now, as you are doing that, I'll be happy to help developing and testing this package. -- 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] z3c.form update issues
2009/2/21 Roger Ineichen d...@projekt01.ch: Hi all I fixed a z3c.form issue where util.Manager keys and values get append more then one time by calling update more then once on widgets or actions. For doing so, I implemented a UniqueOrderedKeys class for util.Manager._data_keys and a decorator which will prevent to override them. See z3c.form.util.py line: 120 Can you please review if this and let me know it this is compatible with our own z3c.form parts? My motivation to deep into this is to find a better way how we use the update track. I think we should separate the update process into a setup and execute concept. I have the feeling, but could not really tell it right now, that we need to separate execute for prevent calling execute more then once during calling update. Update should get called more then once at least if it comes to calculate button/handler conditions. Because it's possible that an action execute call manipulates something which will change the button condition which we need to recalculate within an action update call. Any hints/ideas about that. Or do you know a good use case for this problem. It also smells to me that the MultiWidget or the ObjectWidgets implementation could be more robust within a better update/execute concept. IIRC, the update and execute phases are already separated for actions (you call actions.update() for setup and actions.execute() for actual execting) and that fact is used in MultiWidget and many custom forms. -- 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] z3c.form update issues
2009/2/21 Roger Ineichen d...@projekt01.ch: we should carefully review this part and probably add action.update after action.execute. Right now, without looking at the code I think we do not update actions after execute. Which could end in bad action handler setup because of skipped action condition handling after execute actions. I'll see later if I take another look at that part. Ah, you mean the update method of the form base classes. Yeah, there's no action update performed after executions currently. But I don't think we should just add another updateActions call after execution as it can be quite expensive. The button actions call their widgets' update methods that performs another thousand of adaptations calls. :) However, the problem is very actual and I personally had it in some of my forms. The most obvious use case is when we use the delete button to delete all entries in the list and then we don't want to show the delete button anymore. One (probably nice) solution that comes in my mind is to make the form somehow aware if it needs to re-update its actions and to provide a way for the action handler to signal about that. Probably, a simple boolean form instance variable will do the trick :) -- 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] z3c.form update issues
2009/2/21 Dan Korostelev nad...@gmail.com: 2009/2/21 Roger Ineichen d...@projekt01.ch: we should carefully review this part and probably add action.update after action.execute. Right now, without looking at the code I think we do not update actions after execute. Which could end in bad action handler setup because of skipped action condition handling after execute actions. ... snip ... One (probably nice) solution that comes in my mind is to make the form somehow aware if it needs to re-update its actions and to provide a way for the action handler to signal about that. Probably, a simple boolean form instance variable will do the trick :) I just checked in a fix like I described above. It seems to work at leasts for tests.:-) Can you please review it? -- 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] Where should I update the translation messages?
2009/2/11 Takeshi Yamamoto t...@mac.com: Hello, I would like to update Japanese translation messages of ZMI of Zope 3. I used to do it with launchpad.net but it seems to be gone. Where should I update the translation messages? Thank you. Translations currently belong to the zope.app.locales package, so you can commit it there, if you have commit rights, or create a report in the zope 3 bugtracker (https://bugs.launchpad.net/zope3). Or you can just send the updated .po file to me and I'll update it in the svn. :-) -- 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] z3c.form 2.0
2009/2/11 Stephan Richter srich...@cosmos.phy.tufts.edu: On Tuesday 10 February 2009, Wolfgang Schnerring wrote: I'd like to introduce this to z3c.form as well (see attached patch). Would it be alright with you for me to commit this to trunk (to then go into the release)? Add a test and you can check it in. :-) Also, please add a note to CHANGES.txt about that you changed the signature of SelectFieldWidget, as it breaks backward-compatibility. Or think a way to avoid that problem. :-) -- 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] z3c.form 2.0
2009/2/10 Stephan Richter srich...@cosmos.phy.tufts.edu: On Tuesday 10 February 2009, Laurent Mignon wrote: With the replacement of zope.app.component import with zope.site, it's no more possible to use z3c.form with Zope2 / Plone :-( Thanks for getting our attention on this. I consider this a show-stopper for 2.0. Dan, let's think about something creative that allows us to use the new and old way, maybe through a special import statement like that: Is the problem in that zope2 still contains zope.* modules in itself and not in the eggs, so if it contain old zope.app.component and the new z3c.form depends on zope.site egg, we get two independent local site implementation that will conflict? If so, I guess we have the similar problem with ITerms that was moved to zope.browser. So, the creative solution could be to prepare a compatibility packages that could be used for zope 2 instead of real zope.site and zope.browser and contain reverse imports of things that were moved from their places in zope2 zope.* packages. However, this should be done by someone who works with Zope2 and that's not me, unfortunately. I hope that new zope2 will just use zope3 modules as eggs and won't maintain a copy of 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 )
Re: [Zope-dev] Translations for zope packages.
2009/2/10 Paul Winkler sli...@gmail.com: On Tue, Feb 10, 2009 at 01:54:54PM +0100, Martijn Faassen wrote: In my mind, the Zope framework should offer facilities to support translating applications. These applications can be composed out of more than a single package, and we want to support the translation memory usecase for that. If the Zope framework defines messages itself itself, it should offer a way for an application that exposes them to have translations as well. IMO it must also be possible for an application integrator to install a package that selectively overrides the default translations. How can that be done? At TOPP, when we used Plone 2 and PTS, we had a hack that allowed us to do this, see eg. https://svn.openplans.org/svn/sputnik/branches/0.9.8/sputnik/zinit.py This allowed us to provide some different (english) translations for the same message ids on two websites (openplans.org and livablestreets.com), just by having the sputnik package installed on one site. So far, I've been unable to find a way to accomplish the same thing with the zope 3 i18n infrastructure, which is blocking us from moving to plone 3 on the site that needs the overrides. Is this even possible? Well, I didn't dig that too deeply, but I guess newer zope.i18n allows us to merge translation catalogs for one domain and they have predictable priority over each other, based on registration order (though that could be developed to give user more control over catalog priorities). So I think it's possible to override some msgids if you do that carefully. :-) -- 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] Translations for zope packages.
2009/2/10 Martijn Faassen faas...@startifact.com: +1 also to have a way to *see* the translations as a single whole, with the possibility to define a message id that is used by many packages. I'm not sure about the last thing. Message objects are bound to one translation domain, so the translation will be looked up only for that domain. However, we could provide some fallback translation domain as well. I'm not sure I get all the details. One question is whether packages that don't have any ZMI (such as zope.container) actually need translations at all? Should it define message ids at all? And if it does, wouldn't it be the job of the application that exposes these message ids to actually offer translations? I believe that it's often useful to have standard translations that can be used out of the box and not making application developers have to translate them every time. But it should be really easy for applications to override them, so we'll have to work on that. -- 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] Where should I update the translation messages?
2009/2/11 Takeshi Yamamoto t...@mac.com: Thank you, Dan. I have sent you an updated Japanese po file just few minutes ago. Can I get a commit right for the next time? Regards. Takeshi Yamamoto Done. Thanks for contribution. BTW, we expect a way of translating messages to change soon, so may be we'll connect them to launchpad translation system as well. -- 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] z3c.form 2.0
2009/2/11 Laurent Mignon laurent.mig...@softwareag.com: Stephan Richter wrote: On Wednesday 11 February 2009, Dan Korostelev wrote: Thanks for getting our attention on this. I consider this a show-stopper for 2.0. Dan, let's think about something creative that allows us to use the new and old way, maybe through a special import statement like that: Is the problem in that zope2 still contains zope.* modules in itself and not in the eggs, so if it contain old zope.app.component and the new z3c.form depends on zope.site egg, we get two independent local site implementation that will conflict? If so, I guess we have the similar problem with ITerms that was moved to zope.browser. Yes zope2 still contains zope.* modules BUT the plone.recipe.zope2install has an option 'fake-zope-eggs' to add fake egg links to Zope 3 libraries, so that setuptools can see and use them for dependencies lookup... zope2 (for my part I use zope-2.11.2) still contain and relay on zope.app.component. It's true that we have two independent local sites implementation since z3c.form depends of zope.site. I think that the only issue is when a call is made to the 'getSite' function provided by zope.site to request the site root. The function is only used 2 times in the code (ImageButtonAction and ImageFieldWidget) to compute the resource url. Since these two classes are registered as adapters, we can provide an override for zope2. (maybe into plone.z3cform...) I don't have a similar problem with ITerms since I've updated my code to use the ITerms provided by zope.browser. But, when I execute a 'grep' on the plone code itself, I found four potential issues: plone/app/form/widgets/uberselectionwidget.py plone/app/vocabularies/catalog.py plone/app/vocabularies/groups.py plone/app/vocabularies/users.py Yeah. So one solution, as I said before is to release zope.sitecompat egg that provides a zope.site module, but doesn't implement a site implementation, but instead imports things from old zope.app.component (as does the new zope.app.component reversely). The same thing could be done for zope.browser. However, this is an ugly solution, so I hope Zope2 will move to eggs completely soon, so we won't have to deal with problems like that. -- 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] z3c.form 2.0
2009/2/11 Stephan Richter srich...@cosmos.phy.tufts.edu: On Wednesday 11 February 2009, Dan Korostelev wrote: Yeah. So one solution, as I said before is to release zope.sitecompat egg that provides a zope.site module, but doesn't implement a site implementation, but instead imports things from old zope.app.component (as does the new zope.app.component reversely). The same thing could be done for zope.browser. However, this is an ugly solution, so I hope Zope2 will move to eggs completely soon, so we won't have to deal with problems like that. If that works, +1. Yeah, and so we're able not to deal with that in z3c.form itself and not to delay the release. Though I'd like this things to be done by someone who actually works with Zope2/Plone + z3c.form. Anyone? -- 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] Translations for zope packages.
2009/2/10 Adam GROSZER agros...@gmail.com: In short, a good translation is consistent. That means the same sentences are translated to the same foreign sentence. A so-called translation memory is used for that. Also terms (specific words or expressions of the domain) are translated to the same foreign term. Well, I have a general idea about what translation memory is. I just wanted to clarify how we are going to implement that for zope eggs. So, as far as I understand now, our localization migration process should be like that: 1) create a separate translation domain for every package (so, the zope.container domain for the zope.container package) 2) merge catalogs provided by current zope.app.locales with every package's translations into the package's own domain (so we get all packages somehow translated). 3) write a tool (probably a buildout recipe) that collects translations from multiple packages into one PO/TMX/whatever file for using it as a translation memory file for translation tools. 4) call for translators 5) ... 6) PROFIT! :-) Correct me if I'm wrong. It would also cool to integrate it with launchpad translation system, but I didn't look at that yet. -- 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] z3c.form 2.0
2009/2/10 Laurent Mignon laurent.mig...@softwareag.com: The problem encountered is that zope.container specify ZODB3 as a main dependency. After checking the code, it seems that ZODB is only required for tests. If I modify zope.container.setup.py to specify ZODB3 as an extra dependency for test target, everything works fine. Hmm.. zope.container actually uses BTrees from the ZODB3 egg module for implementing BTreeContainer. -- 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] z3c.form 2.0
2009/2/10 Laurent Mignon laurent.mig...@softwareag.com: Dan Korostelev wrote: 2009/2/10 Laurent Mignon laurent.mig...@softwareag.com: The problem encountered is that zope.container specify ZODB3 as a main dependency. After checking the code, it seems that ZODB is only required for tests. If I modify zope.container.setup.py to specify ZODB3 as an extra dependency for test target, everything works fine. Hmm.. zope.container actually uses BTrees from the ZODB3 egg module for implementing BTreeContainer. And BTrees is also available into Zope2 but I agree that therefore ZODB3 seems to be a normal dependency.. I'm really not an expert and I don't know how it's possible to fix such kind of problem... Well, I'm no Zope2 expert at all, but isn't there some fake eggs support in recent Zope2/Plone buildouts created for handling problems like that? -- 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] z3c.form 2.0
So here's a little review on current status of z3c.form. Mostly based on items from CHANGES.txt for 2.0 release :) I may forget something, so I'll reply to myself if something suddenly comes in my mind. And sorry for my English, i'm quite in hurry now. :-) FileWidget - It doesn't clear the bytes value if no new file is uploaded now, which is nice. But there's also should be a way to clear current value if the field is not required. I've added that to the TODOS.txt. I think that should be done before release to make the widget actually functional out of box. TextLinesWidget - Works. I've fixed a case when a field has tuple in its _type, so it hopefully will work in any case now. MultiWidget - Probably needs some review as it does the updateWidgets thing on value property setting, which seems fishy to me. It works however. I've added the check for min_length and max_length and conditional buttons in the browser version. One thing I'd like to see is that it generate a default number of input rows based on field's minimal length if there's any. Also, another thing that would be nice is to have a way to reorder values for orderable fields. However this can wait for next release. I've added that to the TODOS.txt. ObjectWidget/ObjectMultiWidget - ??? I didn't checked that out, so it would be nice if its author reviewied it and wrote here about its status. Source support - Seems to work fine. I've checked that out in my sandbox instance with zc.sourcefactory's context-less and context-based sources. However, there was some backward-incompatible refactorings (class renames) done to sequence data converters that breaks the z3c.pt benchmarking suite. This may also break end-users' code so we probably want to fix the compatibility. z3c.pt support - ??? I don't use the z3c.pt myself, so I didn't really checked that out. As I said before, the benchmarking suite is borked. Also, there's a strange bug with macros (see below). Also, we need to migrate to z3c.ptcompat instead of z3c.pt.compat (UPDATE: the merge was done while I was writing this). Tests - All are passing. However there was a failure with z3c.pt, I've described before. I don't know what's wrong there, but found a little workaround. See my comment in the tests/simple_groupedit.pt file. (UPDATE: tests are now borked again as a result of merging z3c.ptcompat branch while I was writing this). Translations - I've updated the template and the russian translation to be complete. I don't expect any msgid changes, so I think translators should review their translations and commit them right now :) Also, I wanted to add browser widget attributes like klass or onclick to adaptable values. This will require some work to make browser widgets automatically add their adaptable values to _adapterValueAttributes before calling parent's update method. I'm not sure that I'll be doing that very soon as it isn't very important. So this is definetely not a reason to wait with the release. One more thing I'd like to do is to add klass and id to the forms themselves so one could easily customize the visual appeal of the forms. But it's probably should be done in z3c.formui's subclasses and not in z3c.form's base classes. I'd like to hear the community opinion on that though. -- 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] Translations for zope packages.
Nowadays, when we have a fully egg-based setup, the translations in the zope.app.locales package make no sense anymore as it's very hard to maintain them and it just wrong (to me at least) to have a separate centralized translations package for a hundred of eggs. The zope.i18n = 3.5.0 have a feature of merging multiple message catalogs registered for the same domain. So we have two options here: a) Continue use the zope translation domain for all packages and make each package provide own message catalog to be merged into zope domain. b) Make every package provide its own translation domain. So say zope.container will have and register its own domain named zope.container. Either option is fine with me, however b) helps to avoid msgid clashes, whle a) allows us to reuse msgids. I'd like to hear community opinion on that and after we decide which option to choose I volunteer to migrate current zope.app.locales translations to every egg that have msgids, previously translated by zope.app.locales. However, that's kinda pain in the ass and I'll gladly accept any help on that. :-) -- 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] Planning for Zope 3.5
2009/2/9 Tres Seaver tsea...@palladion.com: I would rather move the Twisted support out into a non-core package, and focus on making the Zope3 components play nicely with *any* WSGI-compliant server. The fact that we still have a forked Twisted in Zope3 is directly tied to the absence of a crucial component in the released version of Twisted. Well, it's already not so bad. The zope.app.twisted is not the core package, and the zope.app.wsgi makes it easy to get the WSGI application of Zope. I've also just checked in an app_factory for PasteDeploy for it, so it can be used as an application component in the PasteDeploy pipeline without any additional python code. The zope.publisher also provides a simple WSGI application for use with paste. -- 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] Translations for zope packages.
2009/2/10 Stephan Richter srich...@cosmos.phy.tufts.edu: On Monday 09 February 2009, Dan Korostelev wrote: Nowadays, when we have a fully egg-based setup, the translations in the zope.app.locales package make no sense anymore as it's very hard to maintain them and it just wrong (to me at least) to have a separate centralized translations package for a hundred of eggs. I think that while having a centralized translations package make no sense anymore, I think we should still maintain a canonical translation memory that serves as the authoritative translation for all packages. This provides consistency across packages and is the way it is done in the professional localization business. So basically, option (b) with option (a) as translation memory. Can you explain that once more? Do you mean that we translate each package in its own translation domain and then collect messages from all packages to a global translation domain that is used only as a translation memory and not for actual i18n of components? -- 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] z3c.form 2.0
2009/2/10 Stephan Richter srich...@cosmos.phy.tufts.edu: On Monday 09 February 2009, Dan Korostelev wrote: FileWidget - It doesn't clear the bytes value if no new file is uploaded now, which is nice. But there's also should be a way to clear current value if the field is not required. I've added that to the TODOS.txt. I think that should be done before release to make the widget actually functional out of box. Since this feature has not been there before, I can live without it for the 2.0 release. Well, if that will be the only issue left, I'm personally also fine with releasing without it :)) However, there was some backward-incompatible refactorings (class renames) done to sequence data converters that breaks the z3c.pt benchmarking suite. This may also break end-users' code so we probably want to fix the compatibility. Yeah, let's fix that. I'll check that. Tests - All are passing. Clearly, all testsshould be passing. In addition, I would really like to see 100% test coverage after taking the false positives into consideration. Ok, the fix for the z3c.ptcompat merge break was to provide a zope.testing.doctest as a doctest module for testing.OutputChecker, so all tests pass again. They are also mostly 100% covered. Most uncovered bits are in the ObjectWidget, MultiWidget and its combination. So those modules defenitely need a review. :-) If translations are not updated until the next release, 2.1.0 or 2.0.1, that's fine with me. Well, that's actually fine with me as well (as I've already updated my translation :-P), so that was a call for people who wants to get their translations ready for 2.0.0. One more thing I'd like to do is to add klass and id to the forms themselves so one could easily customize the visual appeal of the forms. But it's probably should be done in z3c.formui's subclasses and not in z3c.form's base classes. I'd like to hear the community opinion on that though. All nice to have. :-) I would not block the release because of it. That's fine with me to do that for the next release. BTW, I just discovered that forms have the id attribute, but it really points to the name which is a read-only property based on prefix, so they are not customizable at all. Was that done on purpose? I'd just set those attributes in the `update` method of the form. What do you think? -- 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] Planning for Zope 3.5
2009/2/8 Hermann Himmelbauer du...@qwer.tk: And something I wonder from time to time is if it would be possible to integrate a recent Twisted release into Zope3, or, even better, directly use the current twisted egg with Zope3. The problem is that the Twisted egg doesn't contain the web2 module, used by zope's twisted-based WSGI server, so we can only try to integrate the latest release into zope.app.twisted itself, downloading the Twisted release using svn:external as we do now. I tried do do that before, but tests failed and I was unable to fix that, as I don't know twisted at all (shame on me). -- 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] ZCML implementations: where should they go
2009/2/8 Dieter Maurer die...@handshake.de: Each individual extra :extra is equivalent to a separate package _extra depending on (and potentially many other things). The extras are just a convenient way to avoid cluttering the distribution namespace. That said, I like a). +1 -- 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] Tests results for Zope 3.5dev KGS
2009/2/8 Christophe Combelles cc...@free.fr: For now I only have the py2.5-64bit slave, but I have similar results, though less tests: http://zope3.afpy.org/buildbot/ 12895 tests, 27 failures, 10 errors I'll add other slaves soon (32bit and py2.6). Great! BTW, can you please set the english locale for buildbots? :) -- 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 )
