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
ModifiableBrowserLanguages implementation - move to
zope.publisher.browser. It's the useful thing that won't introduce any
"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
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
** No cross posts or HTML encoding! **
(Related lists -