[Web-SIG] using WSGI for standard pluggable applications

[Ben Bangert]

On Sep 21, 2005, at 9:54 PM, Shannon -jj Behrens wrote:

> 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 ;)

Myghty has inheritance that does the same thing (as its a port of  
Mason).

Whether a framework like Myghty or Aquarium can do inheritance  
skinning isn't completely relevant I believe.

In this case the example I perceived was having a unified template  
for multiple, quite likely different, webapps running entirely  
different frameworks. That's why Ian was referring to having Apache  
run output filters, and why Ian and I were referring to a middleware/ 
filter layer that adds the consistent site feel.

Ksenia's original post was talking about having the content from an  
entire webapp would be wrapped into a site template generated by main  
publisher. This would have the advantage of skinning any webapp the  
user wishes to run. (I hope this is what the actual meaning was at  
least)

The reason I say its not really relevant, is because how or what a  
user uses to skin the site, may or may not work well depending on how  
the webapp functions. If the webapp uses an inheritance template  
scheme (like Myghty/Aquarium/others?), then it could be relying on  
the ability to insert code higher up the template chain, all the way  
back to the HTML head.

This is why having a generic skinning webapp thats outside the webapp  
itself (whether a filter/middleware app OR Apache output filter),  
won't really work unless the webapp designer is aware of this and can  
handle the user stripping away sections of the page the webapp  
designer is assuming will exist...

Hopefully that actually makes sense. But in short, some template  
languages lose a lot of power without the ability to do this kind of  
hooking into functions up the inheritance chain. This is why webapp  
ignorant output filters running over the output won't work for those  
webapps.

Maybe people distributing such a webapp should do something to  
indicate that skinning should occur "inside" the app vs having  
something applied "outside"?

Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/web-sig/attachments/20050921/2772ba5a/attachment.html