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
* 2009-08-21 21:07, Dan Korostelev wrote:
IXMLRPCPublisher adapters for zope.container - move them to zope.container. The IBrowserPublisher adapters that are already there, so it won't make things worser. The zope.container package may be refactored later to break dependency on zope.publisher though.
-1, I think this is bad and we shouldn't do it: zope.container has nothing to do with the publisher, and it shouldn't depend on it. The fact that we already have the adapters for IBrowserPublisher shouldn't be a reason to bring more publisher-related stuff over there. Fabio
2009/8/21 Fabio Tranchitella <kobold@kobold.it>:
* 2009-08-21 21:07, Dan Korostelev wrote:
IXMLRPCPublisher adapters for zope.container - move them to zope.container. The IBrowserPublisher adapters that are already there, so it won't make things worser. The zope.container package may be refactored later to break dependency on zope.publisher though.
-1, I think this is bad and we shouldn't do it: zope.container has nothing to do with the publisher, and it shouldn't depend on it. The fact that we already have the adapters for IBrowserPublisher shouldn't be a reason to bring more publisher-related stuff over there.
Sorry, I didn't explain correctly. Those things are actually simply two ZCML declarations that register traversers that are already defined in zope.container.traversal and used for browser traversing. See for yourself - zope/app/container/xmlrpc/configure.zcml. I think those zcml declarations should be placed together with browser adapter registrations, so people who will be refactoring zope.container could see them. :) -- WBR, Dan Korostelev
2009/8/21 Dan Korostelev <nadako@gmail.com>:
I think it's time to clean the mess in the zope.app.publisher package. Currently it contains many things that could be moved into separate packages or merged with base zope packages. So here's a sketch plan about where to move things:
BTW, I am also waiting for comments from a steering group member, as described in ZTK docs :-) -- WBR, Dan Korostelev
Hi Dan, I'll provide feedback for a few parts of your proposal. Dan Korostelev wrote:
xmlprc - move the IXMLRPCView interface and XMLRPCView base class to zope.publisher as a counterpart to zope.publisher.browser.BrowserView. Move MethodPublisher, MethodTraverser, xmlrpc:view ZCML directive to new "zope.xmlrpcview" package. Also I'd merge MethodTraverser with MethodPublisher to make it easier to understand and to decrease number of entities :)
Few developers care about XML-RPC these days. Most web developers are now working with REST, JSON, and other similar stuff. It's probably best to move all XML-RPC artifacts, including those in zope.publisher, to a single package, so that most developers can safely ignore the XML-RPC code.
IXMLRPCPublisher adapters for zope.container - move them to zope.container. The IBrowserPublisher adapters that are already there, so it won't make things worser. The zope.container package may be refactored later to break dependency on zope.publisher though.
You need Jim Fulton's input on this. I think his latest opinion is that zope.container should have nothing to do with publishing.
IHTTPView and IFTPView interfaces - move that into zope.publisher as a counterpart to IBrowserView. (BTW, shouldn't IBrowserView be a subclass of IHTTPView?)
In zope.app land, sometimes IHTTP* really means INonBrowser*. In other words, sometimes people want to define views just for HTTP ports not intended for web browsers.
IFTPDirectoryPublisher interface - not sure what's this and where is it used. Probably should be moved to zope.publisher.interfaces.ftp as well.
FTP is in the same boat as XML-RPC. Today, very few developers care to provide a dynamic FTP view of anything. WebDAV usually wins over FTP because adding SSL to WebDAV is easy. All FTP artifacts should move to a separate package.
That's all for now. I'd like to see some comments/propositions/objections before I start. Also, maybe there are more beautiful names for new packages?
The names you proposed seem ok. Shane
2009/8/22 Shane Hathaway <shane@hathawaymix.org>:
Hi Dan,
I'll provide feedback for a few parts of your proposal. Thanks
Few developers care about XML-RPC these days. Most web developers are now working with REST, JSON, and other similar stuff. It's probably best to move all XML-RPC artifacts, including those in zope.publisher, to a single package, so that most developers can safely ignore the XML-RPC code.
That's a good point. After a quick look, it seems to be easy to move xmlrpc-related things from zope.publisher and zope.app.publisher to new zope.xmlrpc package. One problem is how to make BBB imports then. It doesn't look good to me to make zope.publisher dependent on zope.xmlrpc for xmlrpc stuff, but moving things without BBB imports will break applications that currently uses zope.publisher xmlrpc. One option is to use the notorious "extra" dependencies, but that needs to be discussed. Other options is to start a big refactoring of zope.publisher, but that is a thing I didn't want to do right now, so the third option is to leave these things until zope.publisher refactoring. ;-)
IXMLRPCPublisher adapters for zope.container - move them to zope.container. The IBrowserPublisher adapters that are already there, so it won't make things worser. The zope.container package may be refactored later to break dependency on zope.publisher though.
You need Jim Fulton's input on this. I think his latest opinion is that zope.container should have nothing to do with publishing.
That's true, but see my reply to Fabio Tranchitella on this topic. :-)
IHTTPView and IFTPView interfaces - move that into zope.publisher as a counterpart to IBrowserView. (BTW, shouldn't IBrowserView be a subclass of IHTTPView?)
In zope.app land, sometimes IHTTP* really means INonBrowser*. In other words, sometimes people want to define views just for HTTP ports not intended for web browsers.
Okay then, let's leave the class hierarchy as is :-)
IFTPDirectoryPublisher interface - not sure what's this and where is it used. Probably should be moved to zope.publisher.interfaces.ftp as well.
FTP is in the same boat as XML-RPC. Today, very few developers care to provide a dynamic FTP view of anything. WebDAV usually wins over FTP because adding SSL to WebDAV is easy. All FTP artifacts should move to a separate package.
Then, there's the same option and the same problem as one for XMLRPC, described above. :-) -- WBR, Dan Korostelev
Am 21.08.2009 um 23:14 schrieb Dan Korostelev:
2009/8/22 Shane Hathaway <shane@hathawaymix.org>:
Hi Dan,
I'll provide feedback for a few parts of your proposal. Thanks
Few developers care about XML-RPC these days. Most web developers are now working with REST, JSON, and other similar stuff. It's probably best to move all XML-RPC artifacts, including those in zope.publisher, to a single package, so that most developers can safely ignore the XML-RPC code.
That's a good point. After a quick look, it seems to be easy to move xmlrpc-related things from zope.publisher and zope.app.publisher to new zope.xmlrpc package. One problem is how to make BBB imports then. It doesn't look good to me to make zope.publisher dependent on zope.xmlrpc for xmlrpc stuff, but moving things without BBB imports will break applications that currently uses zope.publisher xmlrpc. One option is to use the notorious "extra" dependencies,
Another option are conditional imports: only import from zope.xmlrpc when it does not lead to an import error. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hey, Shane Hathaway wrote: [snip]
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.
+1 on this general direction.
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.
+1 as well. I've recorded this information in the Zope Toolkit decisions document, just so we know where we're heading. Regards, Martijn
2009/8/21 Dan Korostelev <nadako@gmail.com>:
Browser view directives (browser:page and friends) - move this to some "zope.browserpage" package and make its structure more clean, so people could understand the magic of browser page class generation. :-)
Silly me, I forgot that browser page directives have the "menu" and "title" arguments to integrate browser pages with menus! But I'd like to see browser pages usable without using that browser menu implementation, so I want to discuss one more proposition: make browser page directives smarter, so they wouldn't depend hadly on menus and support menu item registration for pages only when "zope.browsermenu" is installed (and raise an error if browsermenu is not installed and user tried to use "menu" argument). This won't hurt any current zope.app.publisher's users, but can confuse new users who will be learning these zcml directives. But I am sure that good documentation can help here. :-) -- WBR, Dan Korostelev
Dan Korostelev wrote:
2009/8/21 Dan Korostelev <nadako@gmail.com>:
Browser view directives (browser:page and friends) - move this to some "zope.browserpage" package and make its structure more clean, so people could understand the magic of browser page class generation. :-)
Silly me, I forgot that browser page directives have the "menu" and "title" arguments to integrate browser pages with menus!
But I'd like to see browser pages usable without using that browser menu implementation, so I want to discuss one more proposition: make browser page directives smarter, so they wouldn't depend hadly on menus and support menu item registration for pages only when "zope.browsermenu" is installed (and raise an error if browsermenu is not installed and user tried to use "menu" argument). This won't hurt any current zope.app.publisher's users, but can confuse new users who will be learning these zcml directives. But I am sure that good documentation can help here. :-)
+1 if we can make it smarter to break this dependency (but not too smart; I'm not sure how easy this would be). Regadrs, Martijn
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. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
2009/8/22 Michael Howitz <mh@gocept.com>:
Am 21.08.2009 um 21:06 schrieb Dan Korostelev: [...]
ILogin, ILogout from zope.app.publisher.interfaces.http - looks like these don't really mean anything and are used only in zope.app.security. I'd move them to zope.app.security even without BBB imports (not to make zope.app.publisher dependent on zope.app.security), but maybe I just don't know something about them? :)
z3c.layer.pagelet also uses these interfaces to re-implement login/logout like zope.app.security but by using pagelets and viewlets. So it would be nice to have a better place for these interfaces, so z3c.layer.pagelet does not need to depend on zope.app.security.
Are these interfaces used for anything else than just declaring them as implemented? :-) I don't see much sense in them, because they are too abstract and it's hard to understand what they are for, so I'd get just rid of them in z3c.layer.pegelet. -- WBR, Dan Korostelev
Hi Dan
Betreff: Re: [Zope-dev] Proposal: zope.app.publisher refactoring
2009/8/22 Michael Howitz <mh@gocept.com>:
Am 21.08.2009 um 21:06 schrieb Dan Korostelev: [...]
ILogin, ILogout from zope.app.publisher.interfaces.http -
looks like
these don't really mean anything and are used only in zope.app.security. I'd move them to zope.app.security even without BBB imports (not to make zope.app.publisher dependent on zope.app.security), but maybe I just don't know something about them? :)
z3c.layer.pagelet also uses these interfaces to re-implement login/logout like zope.app.security but by using pagelets and viewlets. So it would be nice to have a better place for these interfaces, so z3c.layer.pagelet does not need to depend on zope.app.security.
Are these interfaces used for anything else than just declaring them as implemented? :-) I don't see much sense in them, because they are too abstract and it's hard to understand what they are for, so I'd get just rid of them in z3c.layer.pegelet.
Everything which has to do with login has nothing to do in z3c.layer.pagelet. z3c.layer.pagelet should only offer a working setup for pagelet based traversal stuff and error handling. Regards Roger ineichen
-- 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 )
Am 24.08.2009 um 22:55 schrieb Roger Ineichen: [...]
Everything which has to do with login has nothing to do in z3c.layer.pagelet. z3c.layer.pagelet should only offer a working setup for pagelet based traversal stuff and error handling.
Until we find a better place for it I'd like to keep it there as it is a basic implementation (ported from zope.app.security) of login/logout using pagelets/viewlets. It is the pagelet version of login/logout as the other parts are the pagelet version of error handling and traversal. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi Michael
Betreff: Re: AW: [Zope-dev] Proposal: zope.app.publisher refactoring
Am 24.08.2009 um 22:55 schrieb Roger Ineichen: [...]
Everything which has to do with login has nothing to do in z3c.layer.pagelet. z3c.layer.pagelet should only offer a working setup for pagelet based traversal stuff and error handling.
Until we find a better place for it I'd like to keep it there as it is a basic implementation (ported from zope.app.security) of login/logout using pagelets/viewlets. It is the pagelet version of login/logout as the other parts are the pagelet version of error handling and traversal.
I was looking another time at the z3c.layer.pagelet package. I agree that the added authentication support is usefull and was missing in the first releases. The loginForm.html pagelet should stay there. But we should move the viewlets to another package since this is optional and another concept which is not really needed by pagelets. e.g. z3c.authviewlet or so. Another reason for moving this viewlets is that this login/ logout viewlets are usfull too without using pagelets. Regards Roger Ineichen
Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
Am 25.08.2009 um 14:39 schrieb Roger Ineichen: [...]
I was looking another time at the z3c.layer.pagelet package.
I agree that the added authentication support is useful and was missing in the first releases. The loginForm.html pagelet should stay there. But we should move the viewlets to another package since this is optional and another concept which is not really needed by pagelets. e.g. z3c.authviewlet or so.
Right. Nice naming idea, I'll put it on my to do list.
Another reason for moving this viewlets is that this login/ logout viewlets are useful too without using pagelets.
Right, too. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi Michael I just implemented z3c.authviewlet and moved the authentication viewlet part from z3c.layer.pagelet into this new package. The z3c.layer.pagelet package does not use the z3c.authviewlet package as a dependency. This means you need to include the z3c.authviewlet package in your buildout.cfg and configure it in your configure.zcml. I just released both packages. Regards Roger Ineichen
-----Ursprüngliche Nachricht----- Von: Michael Howitz [mailto:mh@gocept.com] Gesendet: Dienstag, 22. September 2009 10:43 An: dev@projekt01.ch Cc: Zope Developers Betreff: Re: AW: AW: [Zope-dev] Proposal: zope.app.publisher refactoring
Am 25.08.2009 um 14:39 schrieb Roger Ineichen: [...]
I was looking another time at the z3c.layer.pagelet package.
I agree that the added authentication support is useful and was missing in the first releases. The loginForm.html pagelet should stay there. But we should move the viewlets to another package since this is optional and another concept which is not really needed by pagelets. e.g. z3c.authviewlet or so.
Right. Nice naming idea, I'll put it on my to do list.
Another reason for moving this viewlets is that this login/ logout viewlets are useful too without using pagelets.
Right, too.
Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
Am 24.08.2009 um 19:02 schrieb Dan Korostelev:
2009/8/22 Michael Howitz <mh@gocept.com>:
Am 21.08.2009 um 21:06 schrieb Dan Korostelev: [...] 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.
I looked a bit into the code of z3c.layer.pagelet and it seems that you are right. Only the ILogin interface is used there. (The ILogout interface is the one from zope.authentication which seems to be semantically different from the one in zope.app.publisher.interfaces.http.) Although it is a bad idea to copy interfaces, z3c.layer.pagelet could reinvent ILogin if it is really needed. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
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. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
2009/8/24 Stephan Richter <srichter@cosmos.phy.tufts.edu>:
On Friday 21 August 2009, Dan Korostelev wrote:
BrowserSkinsVocabulary - this can be moved to zope.publisher.browser and rewritten with zope.schema's SimpleVocabulary not to introduce dependency on zope.componentvocabulary.
-1. Why? The reason we wrote the zope.componentvocabulary code originally was exactly to avoid the constant reimplementation of that code.
Well, the only reason is that zope.publisher currently doesn't depend on zope.componentvocabulary. But it doesn't matter for me personally, so if steering group decides that it's okay to add a dependency on zope.componentvocabulary to zope.publisher, I won't rewrite the vocabulary with SimpleVocabulary :-) -- WBR, Dan Korostelev
Dan Korostelev wrote:
2009/8/24 Stephan Richter <srichter@cosmos.phy.tufts.edu>:
On Friday 21 August 2009, Dan Korostelev wrote:
BrowserSkinsVocabulary - this can be moved to zope.publisher.browser and rewritten with zope.schema's SimpleVocabulary not to introduce dependency on zope.componentvocabulary. -1. Why? The reason we wrote the zope.componentvocabulary code originally was exactly to avoid the constant reimplementation of that code.
Well, the only reason is that zope.publisher currently doesn't depend on zope.componentvocabulary. But it doesn't matter for me personally, so if steering group decides that it's okay to add a dependency on zope.componentvocabulary to zope.publisher, I won't rewrite the vocabulary with SimpleVocabulary :-)
For the reasons of code stability let's rely on zope.componentvocabulary then, at least for now. zope.componentvocabulary doesn't look like it adds serious dependencies. Regards, Martijn
Hi there, Here are some steering-groupish responses. General note: I'm quite enthusiastic about the general plan to clean up zope.app.publisher! Thanks for bringing this up! Dan Korostelev wrote:
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.
+1. You noted elsewhere there's a dependency from the browser:page directive on this too. If you can make it smart enough in a simple way to only depend on it if zope.browsermenu is actually installed, let's do that.
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. :-)
+1.
BrowserSkinsVocabulary - this can be moved to zope.publisher.browser and rewritten with zope.schema's SimpleVocabulary not to introduce dependency on zope.componentvocabulary.
As noted elsewhere, let's keep the dependency on zope.componentvocabulary for now, unless this introduces more dependencies to zope.publisher in *addition* to the introduction of zope.componentvocabulary itself.
ManagementViewSelector (the @@SelectedManagementView.html view) - leave it there as is.
+1. Anything ZMI-ish stays.
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.
+1 on this strategy, also about factoring out zope.ptresource. This is a less commonly used resource anyway as far as I know, as resources are generally assumed to be static.
ModifiableBrowserLanguages implementation - move to zope.publisher.browser. It's the useful thing that won't introduce any new dependencies.
+1
"date" fieldconverter - I don't think anyone uses it, I'd leave it there as is and forget about it :)
I'm not sure about fieldconverters in general. Shane worked on a WSGI implementation of fieldconverters instead. We could move it zope.publisher fairly easily, except that it depends on parseDateTime in zope.datetime. Let's leave it there for the time being, and see what happens. We can always move it later.
http.zcml - this file contains security declarations for zope.publisher's HTTP-related classes. move them to zope.publisher.
+1
xmlprc
As noted elsewhere, I'd be nice if we had a zope.xmlrpc which consolidated all the XML-RPC related code into a single package. Same applies for FTP support. We don't need to fully figure this out yet to start pulling some of the other stuff out first, though.
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? :)
I'll follow your decision here, I saw some further discussion elsewhere..
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?
Concerning naming: You have zope.browsermenu, zope.browserpage, zope.browserresource. I propose instead we name them zope.menu, zope.page and zope.resource. I think we can safely claim these names in the 'zope' namespace as these *are* the Zope Toolkit menu, page and resource implementations. If we can consolidate the XML-RPC and FTP-related code into separate packages as well, we'd end up with zope.xmlrpc and zope.ftp too. Regards, Martijn
2009/8/25 Martijn Faassen <faassen@startifact.com>:
You have zope.browsermenu, zope.browserpage, zope.browserresource. I propose instead we name them zope.menu, zope.page and zope.resource.
-1 These things are really only for browser, and ZCML directives are in "browser" namespace, while, for example, "zope.resource" is a quite abstract name that could be taken by more appropriate package in future.
I think we can safely claim these names in the 'zope' namespace as these *are* the Zope Toolkit menu, page and resource implementations.
I'm not sure if they are "reusable without having to buy into the rest of the Zope Toolkit". Currently these packages have a note that they are not reusable, as recommended in steering group decisions list, because they depend on the publishing system, which is a really large part. -- WBR, Dan Korostelev
Dan Korostelev wrote:
2009/8/25 Martijn Faassen <faassen@startifact.com>:
You have zope.browsermenu, zope.browserpage, zope.browserresource. I propose instead we name them zope.menu, zope.page and zope.resource.
-1 These things are really only for browser, and ZCML directives are in "browser" namespace, while, for example, "zope.resource" is a quite abstract name that could be taken by more appropriate package in future.
The namespace argument is a good point, but I have my doubts we'll find something more *real* for the menu, resource or page implementation of the ZTK than the ones we've all been using for many many years now. I'm +0 about zope.browser*, and still prefer zope.page and friends. Anyway, we'll keep them as you made them as you already did the work, I don't think anyone really minds these names. Regards, Martijn
participants (8)
-
Dan Korostelev -
Fabio Tranchitella -
Martijn Faassen -
Michael Howitz -
Roger -
Roger Ineichen
-
Shane Hathaway -
Stephan Richter