Re: [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

_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: 
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com