Comments on: Redesign of zope.publisher

By: Links for February 10th |

Links for February 10th | — Wed, 14 Jul 2010 23:10:17 +0000

[...] Picklebytes » Blog Archive » Redesign of zope.publisher – # The IPublication interface and all its implementations should die, to be replaced with a WSGI pipeline. This should make the publication process dramatically easier to understand and customize. # Request and response objects should just hold information; they should have no interesting behavior such as traverse(). # We should create and use two new keys in the WSGI environment, “zope.request” and “zope.response”. These will implement at least IRequest and IResponse, respectively. (”transaction” and “zope.interaction” are also possibilities.) # The WSGI-compatible pipeline should be capable of doing everything zope.app.publication currently does. We should use Repoze packages in that pipeline where possible. [...]

By: Martijn Faassen

Martijn Faassen — Tue, 10 Feb 2009 16:04:36 +0000

Repoze is doing bits of what we need (which is why Shane mentions we should use Repoze packages wherever we can). Shane’s project is to overhaul the existing Zope framework publisher though. repoze.bfg has gone another way and has instead created a much simpler publisher that isn’t trying to be compatible to Zope’s in any way, as repoze.bfg is a new web framework based on zope concepts and smaller bits of the Zope framework than the Zope 3 app server or Grok do. If we want the Zope framework to evolve we’ll have to do things like what Shane’s doing.

see also various comments on Shane’s previous blog entry on this: http://shane.willowrise.com/ar.....zublisher/

By: Luciano Ramalho

Luciano Ramalho — Tue, 10 Feb 2009 14:56:10 +0000

Hey, Shane, it’s great to know that you’re interested in contributing to the Zope core again. I am quite distant from Zope nowadays. But from a distance, your post made me wonder: is that what Chris McDonough and others are doing in Repoze?

By: Martijn Faassen

Martijn Faassen — Tue, 10 Feb 2009 12:43:49 +0000

It sounds good from the perspective of someone fairly uninformed about the specifics. If you can let me know about specifics things people can do to help, I’ll look into helping.

Concerning Brandon’s comments about skinning; I think we should continue with approach to provide an additional skin layer to the request. Of course this affects traversal, but the request *will* affect traversal anyway. The point is that the request shouldn’t have code that is involved in traversal.

I’ll also comment that Zope’s request object is factored out into all sorts of base classes to a rather great extent. I can see how some of the base classes might be useful now to support a test request, but what other purpose do they really have? We should consider whether we cannot flatten this hierarchy significantly. What I’d like to explore as well is a way to start using the webob request and response objects, as they’re a nice WSGI-based library that just cares about web framework request and response behavior. Perhaps we can at least start using them underneath and let Zope’s request and response object adapt them for backwards compatibility’s sake?

By: Brandon Craig Rhodes

Brandon Craig Rhodes — Tue, 10 Feb 2009 12:23:33 +0000

I think these are very good ideas — especially making requests and responses inert. I do not quite understand them at the moment, but from looking at Grok’s skin and layer support, I think that inertizing the request object in particular is really needed if Zope is going to become at all comprehensible to normal web developer terminology.

But at the same time, I’m not an expert who can really comment on your specifics. I’ll post a link to this to the Grok mailing list and see if I can get Martijn to respond to you.