Re: [Zope-dev] Removing dependency between zope.location and zope.copy
2009/12/22 Fabio Tranchitella : > 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/28 Stephan Richter : > 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] SVN: Sandbox/nadako/zope.app.publisher/ Clean up dependencies.
2009/8/27 Stephan Richter : > 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] zope.app.publisher refactoring status
2009/8/25 Martijn Faassen : > 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/25 Martijn Faassen : > 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 )
[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] Proposal: zope.app.publisher refactoring
2009/8/22 Michael Howitz : > 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 )
Re: [Zope-dev] Proposal: zope.app.publisher refactoring
2009/8/24 Stephan Richter : > 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] Deprecated code in zope.location
2009/8/23 Fabio Tranchitella : > * 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 )
Re: [Zope-dev] Proposal: zope.app.publisher refactoring
2009/8/21 Dan Korostelev : > 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] Proposal: zope.app.publisher refactoring
2009/8/22 Shane Hathaway : > 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 : > 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/21 Fabio Tranchitella : > * 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] Deprecated code in zope.location
2009/8/21 Fabio Tranchitella : > 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 )
[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] chameleon.core removes the meta http-equiv="content-type" tag
2009/8/14 Jim Fulton : > On Fri, Aug 14, 2009 at 9:07 AM, Dan Korostelev 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] 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 :
> 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 / 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] Proposal: refactoring of zope.app.security
2009/3/20 Christian Theune : >> > - _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 )
[Zope-dev] zope:view directive
2009/3/16 Michael Howitz : > 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 )
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 : > 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 )
Re: [Zope-dev] setting missing minimum version in setup.py
2009/3/16 Martijn Faassen : >> 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 )
[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] Death of local/persistent permissions (zope.app.security refactoring)
2009/3/13 Dan Korostelev : > 2009/3/11 Martijn Faassen : >>>>> - 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] zope.app.security refactoring results
2009/3/13 Dan Korostelev : > 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 )
[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.site
2009/3/13 Christian Theune : > 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] Death of local/persistent permissions (zope.app.security refactoring)
2009/3/11 Martijn Faassen : >>>> - 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? -- 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/13 Lennart Regebro :
> On Mon, Mar 9, 2009 at 23:35, Dan Korostelev wrote:
>>>>> def hello(who:'name') -> None:
>> ... print('Hello, {0}!'.format(who))
>> ...
>>>>> hello.__annotations__
>> {'who': 'name', 'return': None}
>
> Yup. So, it's stored on the function, not the class. Hence, it will not
> collide.
> Might be confusing though.
As I said before, even if python itself won't add __annotations__ to
some callable objects, this thing may be done by third-party tools.
The PEP doesn't restrict annotations to functions only, instead
there's a note that any callable thing can be annotated 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] 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] Release of zope.component (was [Checkins] SVN: zope.component/trunk/ Merge the 'tseaver-wo_zope_deferredimport' branch)
2009/3/12 Martijn Faassen : > Dan Korostelev wrote: >> 2009/3/12 Martijn Faassen : >>> 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 )
Re: [Zope-dev] Common permissions (final bits of zope.app.security refactoring)
2009/3/12 Martijn Faassen : > 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] z3c.form - creating a file upload widget
2009/3/12 Stephan Richter : > 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] Release of zope.component (was [Checkins] SVN: zope.component/trunk/ Merge the 'tseaver-wo_zope_deferredimport' branch)
2009/3/12 Martijn Faassen : > 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] New package: zope.authentication AND the problem.
2009/3/12 Martijn Faassen : > 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 )
[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 )
[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] 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 )
Re: [Zope-dev] Proposal: refactoring of zope.app.security
2009/3/12 Martijn Faassen : > Hey, > > Dan Korostelev wrote: >> 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. > > It defines the registry and the ZCML directives to fill the registry > both, right? I mean, we could think about calling it zope.principalzcml > but if the registry is there I imagine it's indeed better to make it > zope.principalregistry. Registry is there as well, so it's a fully-functional non-persistent implementation of IAuthentication utility. -- 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 )
Re: [Zope-dev] Proposal: refactoring of zope.app.security
2009/3/12 Benji York : > On Wed, Mar 11, 2009 at 1:52 PM, Dan Korostelev wrote: >> 2009/3/11 Martijn Faassen : >> >>> 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. > > > Maybe we can use the "description" or "long_description" field > in the setup.py for the "package mission statement" > 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] Dependencies for ZCML
2009/3/11 Martijn Faassen : >> 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] zope.localpermission and the "zope app permissions"
2009/3/11 Martijn Faassen : > 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 )
Re: [Zope-dev] Proposal: refactoring of zope.app.security
2009/3/11 Martijn Faassen : > 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 thi
[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] z3c.form: nested group
2009/3/11 Laurent Mignon : > 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 )
Re: [Zope-dev] zope.password
2009/3/11 Martijn Faassen : > Hi there, > > Okay, having read the whole thread, there seem to be two forces pulling > on zope.password: > > * it'd be nice if zope.password had the vocabulary so that you didn't > have to include zope.app.authentication anymore just to get it. > > * it'd be nice if zope.password didn't need any extra dependencies, > including zope.component and zope.schema. > > I think the latter is the least important right now, especially since > zope.component and zope.schema are already very foundational libraries. > So just add the vocabulary to zope.password if that is the only new > dependencies it will pull in as a result. I've moved the vocabulary to zope.password again, but I done the "extra" for now, until the final decision will be made. > In my opinion going for an extra here just to avoid this is speculating > a bit too much right now. Do we really have users that want to use > zope.password and really don't want zope.component and zope.schema? If > so, we'll hear from them when they speak up and *then* declare an extra > or take some other action. Well, as I said before, I wanted to use zope.password in my old Pylons application that only uses zope.interface currently. I don't expect it to be developed in more zope-ish way (though I don't expect it to be developed much in near future :)), so I'd like to avoid these 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 )
Re: [Zope-dev] Proposal: refactoring of zope.app.security
2009/3/11 Martijn Faassen : > Dan Korostelev wrote: >> 2009/3/11 Roger Ineichen : >>>> 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. > > You would expect from the naming that bits of zope.app.authentication > would end up in zope.authentication as well. Yep, that can be expected from the naming, but really, zope.app.authentication is just one of implementations, like z3c.authenticator and we need a package that contains IAuthentication interface & co. that are currently contained in zope.app.security. I think that there's no better name for that package than zope.authentication. > I think that at least some of the bits in zope.app.authentication could > be factored into something like zope.pluggableauth though. I agree. However, may be the better name is zope.pluggableauthentication? Anyway, that can be done later. There's no need to touch zope.app.authentication to do zope.app.security refactorings, when zope.password is now extracted -- 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 : >> >> - 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). > > Do you expect bits of zope.app.authentication could also move to > zope.authentication or does that look implausible? No, I don't think that anything from zope.app.authentication should go to zope.authentication. It probably should go to something like zope.pluggableauthentication. I expect zope.authentication to be tiny package that only define interfaces and very basic utilities. >> - Move global principal registry, its IPrincipal/IGroup >> implementations and its directives into new zope.principalregistry >> package. > > Why not name it zope.principal? It sounds confusing to me. Also, the global principal registry is just an (one of) implementation of IAuthentication, while zope.principal sounds like something from the "core" of principals. >> - 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. >> - 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. > > Move them where? Oh, that's a typo. Move them to zope.security. >> 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. >> - 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. > > Wouldn't zope.publisher then need to depend on zope.principalregistry > for the IPrincipal interface? No. IPrincipal is defined in zope.security. > In general, I'd be careful to execute each of these as a separate step, > and not try to do them all at once. It's quite possible that while > you're moving stuff around (including tests) that you'll suddenly think > of a better place, so better treat this on a case by case basis when you > actually start. Yeah, I was already planning to that step by step. -- 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 : > 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] Proposal: refactoring of zope.app.security
2009/3/11 Roger Ineichen : >> 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 )
[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] zope.password
2009/3/10 Roger Ineichen : > Hi Steering group, Hanno, Dan > >> Betreff: Re: [Zope-dev] zope.password >> >> Dan Korostelev wrote: >> > 2009/3/10 Hanno Schlichting : >> >> 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 )
Re: [Zope-dev] zope.password
2009/3/10 Hanno Schlichting : > 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] Python3 and attribute annotations.
2009/3/10 Martijn Pieters : > On Mon, Mar 9, 2009 at 23:35, Dan Korostelev 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 Roger Ineichen : > 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] SVN: zope.component/trunk/ Merge the 'tseaver-wo_zope_deferredimport' branch:
2009/3/5 Martijn Faassen : > 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] Python3 and attribute annotations.
2009/3/10 Martijn Pieters :
> On Mon, Mar 9, 2009 at 22:20, Dan Korostelev wrote:
>> 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 don't think they are, according to PEP 3107 they are stored in the
> func_annotations attribute of the function.
No, they are stored in __annotations__. Look here:
http://docs.python.org/3.0/whatsnew/3.0.html#new-syntax
Also:
n...@seasaw:~$ python3
Python 3.0.1+ (r301:69556, Feb 24 2009, 13:51:44)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def hello(who:'name') -> None:
... print('Hello, {0}!'.format(who))
...
>>> hello.__annotations__
{'who': 'name', 'return': None}
> Note that even if the name *where* the same, attribute annotations
> only work on classes and instances, while function annotations only
> apply to functions, not?
Good point. Looks like it is added automatically only for functions/methods. :)
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".
--
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] Question: additional context for IAnnotations adapter?
2009/3/9 Dieter Maurer : > 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 )
Re: [Zope-dev] choice of test runner...
2009/3/8 Chris Withers : > 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] setup.py "extra" dependencies
2009/3/6 Tres Seaver : > -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 )
Re: [Zope-dev] zope.publisher uses deprecated IView
2009/3/6 Tres Seaver : > -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] [Checkins] SVN: zope.file/trunk/ Update package mailing list address. Remove zpkg stuff.
2009/3/5 Benji York :
> On Wed, Mar 4, 2009 at 6:36 PM, Tres Seaver wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Martijn Faassen wrote:
>>> Baiju M wrote:
>>>> On Tue, Mar 3, 2009 at 2:35 PM, Dan Korostelev wrote:
>>>>> 2009/3/2 Tres Seaver :
>>>>>>>> -
>>>>>>> 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] setup.py "extra" dependencies
2009/3/5 Gary Poster : > > 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 )
[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 Martijn Faassen : > 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 )
Re: [Zope-dev] Proposals: more refactoring
2009/3/5 Dan Korostelev : > 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 )
[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] zope3docs -> zopeframework?
2009/3/4 Martijn Faassen : > 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.component/branches/tseaver-wo_zope_deferred/ Branch removing zope.deferred.
2009/3/4 Martijn Faassen :
> Dan Korostelev wrote:
>> 2009/3/4 Tres Seaver :
>>>>> 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?
>
> Because Jim doesn't like "from" imports. :)
I think, it's can be important when we talking about some "coding
style standard", but when from imports are used as a tool to achieve
specific need, I don't think that Jim will object. :)
+1 on dropping zope.deferredimport+zope.proxy dependency 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] [Checkins] SVN: zope.component/branches/tseaver-wo_zope_deferred/ Branch removing zope.deferred.
2009/3/4 Tres Seaver :
>>> 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] SVN: zope.component/branches/tseaver-wo_zope_deferred/
2009/3/4 Tres Seaver : > > - - Due to the 'test' extra, buildout pulls in a bunch of extra > dependencies, which I would like to zap (ZODB? really? just to > verify that the persistent registry survives 'dumps' and 'loads'?) > > - - 'setup.py test' needs 'zope.testing', but then doesn't do anything > (missing metadata). If I added the metadata, the tests would then > pull in those extra packages: maybe I'll work on trimming them down, > too. What's the motivation behind removing test dependenices for functionality that actually requires these dependencies, like ZODB/hookable/etc.? -- 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 : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Dan Korostelev wrote: >> 2009/3/4 Tres Seaver : >>> 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.file/trunk/ Update package mailing list address. Remove zpkg stuff.
2009/3/2 Tres Seaver : >>> - >> 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] Proposal: merge zc.configuration's exclude directive into zope.configuration.
2009/2/26 Martijn Faassen : > Hey, > > On Thu, Feb 26, 2009 at 12:43 PM, Dan Korostelev wrote: > [snip] >>> (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 > > Yes, automation makes things more implicit. This is *not* an argument > that can be used against any and all automation. Hey, I didn't try to argue about anything. It was just my subjective opinion. :-) > An explicit > includeDependencies directive will include the configure.zcml and > meta.zcml of packages that are dependencies of that package. You make > less mistakes this way (and it's very common to make the mistake to > forget inclusion of some ZCML). It's also pretty rare to want to do > otherwise in my experience (and there's always the exclude directive). Well, I guess that it's my personal desire of control. I'll probably change my mind about that, as (thinking now), there are really less things that I don't want to include than things that I want to include. Also, the plugin mechanism looks interesting to me now. :) > I'd also argue auto-inclusion can actually help guard against > dependency bugs, such as cases where a package tries to include ZCML > it doesn't depend on (and works because some other package makes the > dependency installed). Good point. >> slows down startup time for >> applications that uses many eggs. > > When claims like that are made, I'd like to see measurements that > demonstrate significant slowdowns during startup. Undoubtedly more > code is excuted than when you write out 'include' directives manually, > but is the slowdown actually measurable? Well, that's probably a really big mis-use (I even hope so), but I ran into really gross slowdown while working on the z3ext project. They have about 130 eggs (not counting zope 3.4 ones) and each one has the autoinclude directive and a bunch of egg dependencies. So the application startup time on my (not so fast though) computer is about 4-5 mins :-/ So, is z3c.autoinclude intended to be used by any egg, including "feature packages" (like z3c.form) or only for actual applications (like a ZMI instance)? I'd really like if this topic will be cleared up in z3c.autoinclude docs. Also, is there any caching for already processed packages in the include finder code? If no, I'd probably like to contribute some, if I'll use z3c.autoinclude. :) >> 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. > > That's asking for a feature that other packages that *don't* use > autoinclude don't support! You lose control as soon as you include a > package's "configure.zcml". There's no difference with > non-auto-inclusion here; if you include a package's configure.zcml you > get whatever it includes, automatically or using normal zcml include > directives. When auto-inclusion is used all dependencies that use > setup.py are included too. If you want to change that behavior, you > will have to skip importing that package's configure.zcml altogether, > just like in the case where that package does write its include > statements out explicitly. Well, it's quite useful in the "z3ext" case I described above - I could just turn off the autoincluding and carefully write the includes in the instance zcml, so get not so crazy startup time. > Anyway, it's fine if you don't want to use auto-inclusion in a > package, but it's not as arbitrarily magic as you are suggesting here. Thanks, I'll take a look at it again. -- 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 : > 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 )
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 :
> 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] Proposal: merge zc.configuration's exclude directive into zope.configuration.
2009/2/26 Jim Fulton : > >> 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] Proposal: merge zc.configuration's exclude directiveinto zope.configuration.
2009/2/26 Roger Ineichen : >> (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 Martijn Faassen : > 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 )
[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] Zope.pipeline proposal
2009/2/25 Martijn Faassen : > 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] Zope.pipeline proposal
2009/2/25 Shane Hathaway : > Hi all, > > I've put up a draft of a zope.pipeline proposal: > > http://wiki.zope.org/zope3/ZopePipeline > > The proposal is intended to explain my thoughts on the subject more > thoroughly. I like the idea, as it definetely cleans up request processing and publication related things in Zope, so if you'll manage to keep full backward compatibility, a strong +1 on that. :) The pipeline way makes request processing process much more pluggable and componentized. Also, how easy is to integrate existing non-zopeish WSGI middlewares into the zope.pipeline? Like some resource injectors or XHTML slimmers and so on. It would be really great to be able to do that with single ZCML directive. -- 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 : > > 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] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
2009/2/24 Shane Hathaway : > Dan Korostelev wrote: >> >> 2009/2/24 Jim Fulton : >>> >>> 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 )
Re: [Zope-dev] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
2009/2/24 Jim Fulton : > 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] [Checkins] SVN: z3c.mimetype/ Create infrastructure for z3c.mimetype
2009/2/24 Benji York :
> On Tue, Feb 24, 2009 at 8:29 AM, Dan Korostelev wrote:
>> 2009/2/24 Baiju M :
>>> Hi Dan,
>>>
>>> On Tue, Feb 24, 2009 at 6:40 PM, Dan Korostelev 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] [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: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
2009/2/24 Shane Hathaway : > 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 Dan Korostelev : > 2009/2/21 Roger Ineichen : >> 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] z3c.form update issues
2009/2/21 Roger Ineichen : > 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 Roger Ineichen : > 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 2.0
2009/2/11 Stephan Richter : > 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] z3c.form 2.0
2009/2/11 Laurent Mignon : > 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] Where should I update the translation messages?
2009/2/11 Takeshi Yamamoto : > 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] Translations for zope packages.
2009/2/10 Martijn Faassen : > +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] Translations for zope packages.
2009/2/10 Paul Winkler : > 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] z3c.form 2.0
2009/2/10 Stephan Richter : > 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] z3c.form 2.0
2009/2/11 Stephan Richter : > 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] Where should I update the translation messages?
2009/2/11 Takeshi Yamamoto : > 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 )
