[Web-SIG] using WSGI for standard pluggable applications

[Shannon -jj Behrens]

Having multiple levels of shared look and feel is something that
Aquarium does very well in Cheetah using multiple techniques.  I do
make use of heavy OO, etc. to make this happen.  It's a requirement
for my company where we need multiple applications to look pretty much
the same, but not exactly. :-/

Best Regards,
-jj

On 9/21/05, Ian Bicking <ianb at colorstudy.com> wrote:
> 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.
>
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/jjinux%40gmail.com
>


--
I have decided to switch to Gmail, but messages to my Yahoo account will
still get through.