cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [RT] composition vs. inheritance in blocks
Date Thu, 31 Mar 2005 14:44:08 GMT
Daniel Fagerstrom wrote:

> Ralph Goers wrote:
>> Daniel Fagerstrom wrote:
>>> Ok, I'll give you a new example trying to explain the concept. Let's 
>>> start with the portal block and say that I want to use that for my 
>>> app, MyPortal, but I want a different skin. The skin consists of the 
>>> stylesheet "styles/portal-page.xsl" among other things. We assume 
>>> that the designer of the portal block wanted to make the skin 
>>> overridable so there is a sitemap rule that exposes the stylesheet 
>>> in the Portal block.
>>> <match pattern="styles/portal-page.xsl">
>>>   <read src="default-portal-page.xsl"/>
>>> </match>
>>> Now I let MyPortal extends Portal and reimplements the stylesheet in 
>>> MyPortal
>>> <match pattern="styles/portal-page.xsl">
>>>   <read src="my-portal-page.xsl"/>
>>> </match>
>>> and thanks to polymorphism the user of MyPortal will get 
>>> "my-portal-page.xsl" when asking for "styles/portal-page.xsl" and 
>>> everything else will be delivered from Portal.
>> Normally, I try to avoid these "theoretical" posts, but since you are 
>> picking on the portal...  Frankly, if the way you are proposing this 
>> was actually how the portal worked we would not be using it.  
>> Luckily, to do what you are suggesting is as simply as doing 
>> something like:
>> <map:match pattern="styles/portal-page.xsl">
>>  <map:read 
>> src="{globalConfig:/global-variables/skin}styles/portal-page.xsl"/>
>> </map:match>
>> I understand you were trying to make a point, but sometimes I feel 
>> like these diatribes resort to using a sledgehammer where a simple 
>> screwdriver would do the job nicely.
> I based my example on the portal as Carsten asked about how one could 
> use blocks for skins and for the portal (although my example didn't 
> answer his questions). I also chosed it, to make the discussion less 
> theoretical as it in the end is about highly practical things. And I 
> doubt that we will ever get to the "real blocks", if we don't discuss 
> and get feedback on practical usage.
> 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.
> So is it complicated? Not particular. As we use it in our apps we 
> would write:
> <map:match pattern="styles/portal-page.xsl">
> <map:read src="cocoon://{request:sitemapPath}/styles/portal-page.xsl"/>
> </map:match>
Actually, we use
<map:read src="prefs://presentation/styles/.portal-page.xsl"/>

The input source takes care of finding the "correct" version of the file 
based upon who the client is and whether they actually have a file. If 
they don't, the default version of the file is used.  The point is, the 
problem is being attacked where it exists, not by making many 
incarnations of a block. That will get to be unwieldy and cumbersome.


View raw message