[Web-SIG] using WSGI for standard pluggable applications

[Ian Bicking]

Ben Bangert wrote:
> 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).

I don't think "middleware" actually means *anything*, though, except
that it's between two things.  Everything is between two things.

I'm comfortable with filters implying a filtered view of the request
(i.e., environ modifying filter), or filtered view of the response
(rewriter), and if it doesn't completely fit for things like
error-catching, that's okay.  At least it isn't scary.

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

Well, right now at work we're looking at a three-level template: each
page has a template, that inherits from the application template, and
that inherits from the site template.  And then the app can be installed
in different sites by switching the site template.

Right now that's possible if you allow several template directories that
shadow each other.  And you can switch any of the templates, e.g.,
customizing a single page.  A filter can't replace that functionality.
But to the degree that you can change the overall look of the site, you
have to do it for each application, and that makes me sad -- if I have
to use different templating languages for overriding individual pages of
an application, I don't see that as a problem.  But I'd like to be able
to apply a site template ("skin" I guess it's usually called) without
quite so much effort.  I think that's a useful goal.

Right now at work we *are* going to do this, by using a filtered
templating language (SSIs, using an Apache OutputFilter).  An in turn,
we'll create a Single Template for each application that translates that
application's look into SSIs.  From that perspective, you don't actually
have to standardize on anything -- at least if you are deploying a small
number of applications widely it isn't so much of a problem, because the
time invested in converting each application is regained because you can
reuse that conversion for all sites.