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

[Dan Korostelev]

2009/8/25 Martijn Faassen <faassen at startifact.com>:
> 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