[Zope-dev] zope.app.publisher refactoring status

[Martijn Faassen]

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