[Web-SIG] using WSGI for standard pluggable applications

Ian Bicking ianb at colorstudy.com
Sat Sep 10 20:39:48 CEST 2005

Ksenia Marasanova wrote:
> 2005/9/10, Ian Bicking <ianb at colorstudy.com>:
>>Ksenia Marasanova wrote:
>>>Sorry if this is a trivial question, but does it sounds reasonable to
>>>use WSGI for "pluggable" standard applications, instead of usual
>>>Python imports? For example, standard news module, like:
>>>app = NewsApp(path='/site/news/')
>>>The content of news app would be inserted into site template,
>>>generated by main publisher.    If there are any examples of such WSGI
>>>use, I'll be glad to hear that...
>>I think you are describing something along the lines of what Paste
>>Deploy is doing (http://pythonpaste.org/deploy/paste-deploy.html).
> [snip]
> Thanks for the detailed example, I finally understand now what Paste
> does :). One question though, should I use environ for exchanging data
> between applications (e. g. some template object, that partly rendered
> by one application, and should be "finished" by News), or does Paste
> have some facility for that?

You mean like a site template?  I don't really have a very good idea of
how best to handle that :(

One possibility is creating a rendering filter.  So at the top of the
hierarchy, you have some code that filters the output.  Outside of
Paste/WSGI I'm planning on doing this with Apache OutputFilters.  In
WSGI I'm not sure how best to do it -- I think it's too inefficient for
an application to generate template source, and have it rendered later.
 Something like server-side includes, edge-side includes, or XSLT seems
more efficient and reasonable.

Also, you can do subrequests to render several portions of a page.  A
good high-level templating language (like SSI) should make this easy
(should such a thing be written!).  In Paste there is a
filter/middleware in paste.recursive to make subrequests easier.

Then lastly, what you might be thinking of, is a way of passing a
template object to subapplications.  I'd imagine this template should be
fairly simple, at least if it is going to be able to handle applications
that use different templating languages.  I'd imagine it being called like:

  tmpl(var1=foo, var2=bar, ...)

Where at least "body" and "title" are expected.  But even then the
applications have to be modified, since most applications have their own
templating system.  It won't be trivial in any case, but at least it
would be nice to be able (for each application) to have a generic
template.  This is why I think a filter-based system will work better.
One example of a filter is here:

Using XSLT it requires valid XHTML, I'd imagine.  But a text-based
parser is easy enough to imagine.


More information about the Web-SIG mailing list