[Zope-dev] Proposal: zope.app.publisher refactoring

[Martijn Faassen]

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