<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><DIV>On Sep 21, 2005, at 9:54 PM, Shannon -jj Behrens wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Sorry to keep yacking, but one more thing comes into play.<SPAN class="Apple-converted-space">  </SPAN>In</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Aquarium, I have this thing called inverseExtend.<SPAN class="Apple-converted-space">  </SPAN>This allows a</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">parent class, say SharedLayout, to completely and automatically wrap</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">the child class.<SPAN class="Apple-converted-space">  </SPAN>It gets to "go first", call the child when it wants,</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">and do with the output what it wants.<SPAN class="Apple-converted-space">  </SPAN>This is done in Webware too,</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">but for only one level.<SPAN class="Apple-converted-space">  </SPAN>I.e. someone has to define respond (is that</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">the right method name?).<SPAN class="Apple-converted-space">  </SPAN>If you want to repeat this for another step</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">in the hierarchy, you have to come up with a new method name.<SPAN class="Apple-converted-space">  </SPAN>In</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Aquarium, every level defines __call__, and the control flow starts at</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">the top of the inheritance hierarchy and works its way down.<SPAN class="Apple-converted-space">  </SPAN>Each</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">parent wraps the child.<SPAN class="Apple-converted-space">  </SPAN>I took this technique from Mason.<SPAN class="Apple-converted-space">  </SPAN>It's</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">amazing how helpful it is.<SPAN class="Apple-converted-space">  </SPAN>Screen can redefine methods defined by</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">SharedLayout, but SharedLayout can choose to do anything it wants with</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">the output of, say AppLayout.<SPAN class="Apple-converted-space">  </SPAN>Hence, you end up with:</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">AppLayout</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-converted-space">  </SPAN>SharedLayout</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-converted-space">    </SPAN>SectionLayout</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-converted-space">      </SPAN>Screen</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-converted-space">    </SPAN>Section Layout</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-converted-space">  </SPAN>Shared Layout</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">AppLayout</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Ok, hopefully I'll shut up now ;)</DIV></BLOCKQUOTE><BR></DIV><DIV>Myghty has inheritance that does the same thing (as its a port of Mason). </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Whether a framework like Myghty or Aquarium can do inheritance skinning isn't completely relevant I believe.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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...</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Maybe people distributing such a webapp should do something to indicate that skinning should occur "inside" the app vs having something applied "outside"?</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Cheers,</DIV><DIV>Ben</DIV><FONT class="Apple-style-span" color="#0000DD"></FONT></BODY></HTML>