cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <peter.hunsber...@gmail.com>
Subject Re: [RT] composition vs. inheritance in blocks
Date Thu, 31 Mar 2005 14:26:26 GMT
On Thu, 31 Mar 2005 11:51:53 +0200, Daniel Fagerstrom
<danielf@nada.kth.se> wrote:

<snip/>

> Now I'm aware that the portal samples use the construction you show
> above, but it doesn't achieve exactly the same thing as the construction
> I propose. If you want to use a slightly modified skin, I would assume
> that you start by copying the +30 files from skins/commons and then
> point "global-variables/skin" to the new location and start to modify
> whatever you wanted to modify.
> 
> With my solution you just copy the file, in this case "portal-page.xsl"
> that you actually want to modify and write an overriding sitemap rule to
> use it. After having used thing like the global variable trick for a
> number of years in various applications, we had a tremendous amonount of
> different generations of esentially the same files and numerous copies
> of slightly modified sitemap snippets. Hardly supprising it was a
> maintainance nightmare. After having start to use the pattern that I
> propose we have seen a drastic decrease in the number of files in our
> new applications.

One comment: I'd hope that you don't literally copy the
"portal-page.xsl" and modify it?  Instead you should be creating a new
XSL, including "portal-page.xsl" in it and just modifying the
templates that you  wish to override...

I point this out because XSLT implements an interesting version of MI
with include.  It completely exposes the entire inheritance tree and
gives you very limited ways to navigate the tree.  None-the-less
people use it all the time.

In the 70 plus XSLT we have in our app roughly half of them do an
include, sometimes using 4 levels inheritance.  None of them use an
import and an "apply-imports" which would be the XSLT equivalent of
composition.

There are a couple of ways in which XSLT (1.0) could provide better
tools for manging the inheritance tree.  In particular, on include you
should be able to specify the default priority of the included
templates and a base-priority that would be added to any existing
priorities.  You still wouldn't get complete navigation through the
tree, I can see ways of doing that also, but that's another topic
(unless people want to use an XSLT like model for block inheritance.)

<snip/>

-- 
Peter Hunsberger

Mime
View raw message