[Web-SIG] using WSGI for standard pluggable applications

Shannon -jj Behrens jjinux at gmail.com
Thu Sep 22 06:54:11 CEST 2005 

Sorry to keep yacking, but one more thing comes into play.  In
Aquarium, I have this thing called inverseExtend.  This allows a
parent class, say SharedLayout, to completely and automatically wrap
the child class.  It gets to "go first", call the child when it wants,
and do with the output what it wants.  This is done in Webware too,
but for only one level.  I.e. someone has to define respond (is that
the right method name?).  If you want to repeat this for another step
in the hierarchy, you have to come up with a new method name.  In
Aquarium, every level defines __call__, and the control flow starts at
the top of the inheritance hierarchy and works its way down.  Each
parent wraps the child.  I took this technique from Mason.  It's
amazing how helpful it is.  Screen can redefine methods defined by
SharedLayout, but SharedLayout can choose to do anything it wants with
the output of, say AppLayout.  Hence, you end up with:

AppLayout
  SharedLayout
    SectionLayout
      Screen
    Section Layout
  Shared Layout
AppLayout

Ok, hopefully I'll shut up now ;)

Best Regards,
-jj

On 9/21/05, Shannon -jj Behrens <jjinux at gmail.com> wrote:
> Sorry, I didn't mean to sound like I was bragging.  I should note that
> imho this is a bit easier to do with Cheetah than with ZPT and Metal.
> In Cheetah, if I have a deep inheritance hierarchy:
>
> SharedLayout
> AppLayout
> SectionLayout
> Screen
>
> Then, within Screen I can override, extend, or define methods that are
> defined at any level of the hierarchy.  Since everything is defined as
> a method somewhere, Screen can change any part of the look and feel it
> wants.  So can SectionLayout and AppLayout change anything defined in
> SharedLayout.  This is easier to do with inheritance in Cheetah than
> it is to do with Metal macros where the slot mechanism is a bit more
> tedious and explicit.  In Metal you have to fill every slot.  In
> Cheetah, there may be 30 different methods that come into play in the
> inheritance hierarchy, but I only have to redefine the ones I care
> about at the Screen level.
>
> Of course, take these statements with a grain of salt.  I'm currently
> making use of Plone for one project (trying to learn something new),
> and my knowledge of Cheetah is better than my knowledge of ZPT and
> Metal.  Perhaps I'm completely wrong.
>
> Best Regards,
> -jj
>
> On 9/21/05, Shannon -jj Behrens <jjinux at gmail.com> wrote:
> > 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.
> >
>
>
> --
> I have decided to switch to Gmail, but messages to my Yahoo account will
> still get through.
>


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

More information about the Web-SIG mailing list