Philipp von Weitershausen - grok and wsgi¶

WSGI is a specification for the the communication between the "gateway" (where http requests come in) and the "application" (the real thing that does something, in our case the zope publisher). The gateway outputs a python dict of environment variables plus a file-like object that's the request that's coming in. On the way out, you have the output (as an iterable of lines).

Important point: the web application no longer owns the process: no more "zopectl start". The whole process is handled by wsgi. It looks like standard CGI, but much more pythonic.

"Zopeproject" is an early go at running/configuring zope as a wsgi process. zope.app.wsgi.getWSGIApplication(/path/to/zope.conf). Zope.conf refers to the site.zcml, site.zcml loads the rest (for instance a demo grok application that he showed). You can start the application with "paster server deploy.ini" (or with apache's mod_wsgi etc). deploy.ini configures what you want to start via wsgi.

Another advantage is that zc.recipe.egg is enough: you don't actually need buildout and custom recipes to run it. Just zc.recipe.egg, a zope.conf, a site.zcml and a paste.ini.

There was some pushback "the repoze guys are doing it wrong the wrong way", "skeletons should not be used, so paster script is bad" and "that's middleware that's not allowed by wsgi". (I didn't agree with all of that, for the record. Putting the contents of a zcml fine as text in a buildout.cfg: yuck) zope.publisher.paste (mentioned next) removes the need for the most "offensive" generated file, btw.

There's something new out of Jim Fulton's fingers: zope.publisher.paste.Application(). It lets you configure the publication in paste.ini by passing parameters like database (zodb or not), the root object, the zcml file, etc. No more zope.conf, just paste.ini.

We can lower the amount of grok-specific code when we use wsgi. A lot of functionality can be hooked up at standard entry points so that we don't have to hook it up ourselves.

Tags: grokplone