[Web-SIG] using WSGI for standard pluggable applications

[Ben Bangert]

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  
>> 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.

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  
call it).

> 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:
> http://www.decafbad.com/blog/2005/07/18/ 
> discovering_wsgi_and_xslt_as_middleware
>
> 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  
Javascript on body load? etc.

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.

- Ben