[Web-SIG] using WSGI for standard pluggable applications
ben at groovie.org
Wed Sep 21 20:16:51 CEST 2005
On Sep 10, 2005, at 11:39 AM, Ian Bicking wrote:
>> Thanks for the detailed example, I finally understand now what Paste
>> does :). One question though, should I use environ for exchanging
>> between applications (e. g. some template object, that partly
>> 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
> an application to generate template source, and have it rendered
> Something like server-side includes, edge-side includes, or XSLT
> more efficient and reasonable.
I was thinking the exact same thing earlier this morning. It wouldn't
be hard to do, but in the process you'd want the app's deployed to be
customized so a lot of the extra information is not returned. Then
have them run through a webapp acting as a content filter.
My main problem with doing this is speed, as there's now essentially
two full web applications (to an extent) rendering a single page.
> 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.
I'm voting to keep middleware at this point. Filter implies removing
something from what is being 'filtered'. While middleware does that
on occasion, a lot of the middleware I've seen adds to things, not
removes (transaction, sessions, etc) which would make the term
confusing. If there was some pretty graphic with colored boxes and
such showing the WSGI flow and where middleware fits in, less people
would have a problem with it (as I'm not really sure what else you'd
> 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
> 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.
I think its ok to just try and skin each app deployed in a similar
fashion. There's just too many things a sub-section of the page might
rely on elsewhere to reliably skin it at a higher level. What if this
particular page requires a different stylesheet? A different
There's so many things a page could require in the header, footer,
etc. just to operate properly I can't see it being realistic to have
a template filter act very reliably on different deployed apps. While
it does take some extra work to make it all look right from the web
users perspective, I think its worth it since you're at least sure
the deployed apps will run properly.
More information about the Web-SIG