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] zope.app.publisher refactoring status
Hey Dan, See also my feedback in the original thread. Dan Korostelev wrote: > Four new packages have been introduced: See my comment on naming. I think we should call 'zope.menu', 'zope.page', 'zope.resource'. > * 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. Sounds good. > * 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). Cool. > * 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. [snip] > 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. I'm okay with a) and c). It's indeed not much code, though on the other hand it'd be nice to make it reusable anyway. > 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. > 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. 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. Regards, Martijn ___ 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 )
