[Web-SIG] using WSGI for standard pluggable applications

[Shannon -jj Behrens]

On 9/21/05, Ben Bangert <ben at groovie.org> wrote:
> 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).

Yep, I stole it from 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"?

I completely agree.  Is this a real problem that a lot of people face
or is it of academic interest only?  It seems to me that sticking to a
framework for your own code is a very helpful thing.  If you must
support 2 frameworks, recode the common look and feel as you
transition from one framework to the newer framework.  I think trying
to always be completely framework neutral is like trying to use C with
no pointers :-D

I have to deal with upwards of 10 apps across many departments that
all use my shared look and feel.  The way the different apps use
inheritance hooks to subtly change various parts of the page is
intricate.  I'd hate to have to do that using a filter :-/  Oh well,
YMMV.

Best Regards,
-jj

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