Return-Path: 
 <dev-return-72953-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 64745 invoked from network); 3 Apr 2005 16:00:56 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 3 Apr 2005 16:00:56 -0000
Received: (qmail 73698 invoked by uid 500); 3 Apr 2005 16:00:52 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 73630 invoked by uid 500); 3 Apr 2005 16:00:51 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 73615 invoked by uid 99); 3 Apr 2005 16:00:51 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Received: from blossom.betaversion.org (HELO blossom.betaversion.org)
 (62.140.213.100)
  by apache.org (qpsmtpd/0.28) with ESMTP; Sun, 03 Apr 2005 09:00:51 -0700
Received: by blossom.betaversion.org (Postfix, from userid 101)
	id 8F0C0187474; Sun,  3 Apr 2005 17:00:39 +0100 (BST)
X-AntiVirus-Version: ClamAV 0.83/802
X-AntiSpam-Version: SpamAssassin 3.0.2
X-AntiSpam-Status: No (score=1.7/limit=7.5)
X-AntiSpam-Rules: rcvd_in_njabl_dul, listed
Received: from [192.168.1.100] (h-68-166-233-220.cmbrmaor.dynamic.covad.net
 [68.166.233.220])
	by blossom.betaversion.org (Postfix) with ESMTP id 12759187471
	for <dev@cocoon.apache.org>; Sun,  3 Apr 2005 17:00:37 +0100 (BST)
Message-ID: <4250133B.4030306@apache.org>
Date: Sun, 03 Apr 2005 12:00:59 -0400
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] composition vs. inheritance in blocks
References: <42444CFF.4020807@yahoo.de> <42446062.8000404@nada.kth.se>
 <424529B7.2020409@yahoo.de> <4245512C.3000107@nada.kth.se>
 <4248F241.2050503@apache.org> <4249437A.80600@nada.kth.se>
 <424980CB.4030708@apache.org> <42499D1D.6000104@nada.kth.se>
 <4249ED2C.8060408@apache.org> <424A84B7.1000008@nada.kth.se>
 <424AD336.5090804@apache.org> <424B2C2A.7080305@nada.kth.se>
 <424BED74.5050701@apache.org> <424C1F61.3070006@nada.kth.se>
 <424D8C98.7040707@apache.org> <424FDF59.5060800@nada.kth.se>
In-Reply-To: <424FDF59.5060800@nada.kth.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N



Daniel Fagerstrom wrote:
> Stefano Mazzocchi wrote:
> 
>> Daniel Fagerstrom wrote:
>>
>>> Concerning the skin I find it somewhat burocratic to need to define a 
>>> new block for beeing able to extend it but I'm ok with it for the 
>>> time beeing, we will see when we start to use the things. 
>>
>>
>>
>> Cool.
>>
>>> What I would prefer would be to do something like:
>>>
>>> MyPortal Sitemap
>>> ----------------
>>>
>>> ...
>>> <pipeline>
>>>  <match pattern="load-user-profile">
>>>    ...
>>>  </match>
>>>
>>>  <match pattern="skin/one-special.css">
>>>    <read src="styles/css/one-special.css"/>
>>>   </match>
>>>
>>>  <mount uri-prefix="skin" src="blocks://skin"/>
>>>
>>>  <mount uri-prefix="" src="blocks://portal"/>
>>> </pipline>
>>> ...
>>>
>>>                                  --- o0o ---
>>>
>>> So what do you think about this?
>>
>>
>>
>> Did you really mean the above or you meant
>>
>>  <mount uri-prefix="skin" src="block:skin://"/>
>>  <mount uri-prefix="" src="block:portal://"/>
> 
>  >
>  > ?
> 
> I meant what you suggest, I adapted my notation to Reinhard's example.
> 
>> in that case, and the above is your sitemap mount at /, how do you 
>> avoid the conflict emerging by the fact that somebody else has mount 
>> another implementation of the skin block on /skin ?
> 
> 
> I general I would only mount applications or applications that are 
> packaged as a block to an external path. The blocks that just are part 
> of applications will only get accessed through the blocks protocol. And 
> its quite likely that I want to control or adapt the uri space from the 
> used block (skin e.g.) in my application which only is possible if I 
> serve it through the sitemap of my application.
> 
> In the example above I would only have mounted MyPortal if I acually 
> used it as an application and not as a building block in another 
> application. And I would only have mounted it at "/" if it was the sole 
> or main application within my Cocoon instance. So I don't see why I 
> should get any conflicts.
> 
> Furthermore it's not either or, if you have some good reason for 
> mounting all your (building) blocks at the exposed uri space of your 
> Cocoon I have no plans in trying to stop you from it ;). Then you should 
> of course avoid mounting them so that they shadow the uri space of other 
> blocks or your applications.
> 
>> Daniel, I perfectly understand why you want those features, but I have 
>> a bigger goal: allow blocks to be really polymorphic, not just an 
>> easier deploy tool.
> 
> 
> Cool, then we share the same goal. Real polymorphism means that if I 
> have two classes:
> 
> public class Base {
>   public String name() { return "Base"; }
>   public String msg() { return "I'm " + foo(); }
> }
> 
> public class Extended extends Base {
>   public String name() { return "Extended"; }
> }
> 
> then
> 
> Extended e = new Extended();
> System.out.println(e.name());
> 
> will obviously print "Extended".
> 
> and
> 
> System.out.println(e.msg());
> 
> will print "I'm Extended" rather than "I'm Base".
> 
>                                   --- o0o ---
> 
> Translating this to blocks we get:
> 
> BaseBlock Sitemap
> -----------------
> 
> <pipeline>
>   <match pattern="content">
>     <read src="base-content.xml"/>
>   </match>
> 
>   <match pattern="view">
>     <generate src="blocks:/content"/>
>     <transform src="content2html.xsl"/>
>     <serialize/>
>   </match>
> </pipeline>
> 
> ExtendedBlock Sitemap
> ---------------------
> 
> ExtendedBlock extends BaseBlock
> 
> <pipeline>
>   <match pattern="content">
>     <read src="extended-content.xml"/>
>   </match>
> </pipeline>
> 
> Saying that we mount ExtendedBlock at "/" then
> 
>   /content
> 
> obviuosly will respond with the content of "extended-content.xml"
> 
> with mere shadowing
> 
>   /view
> 
> would respond with an html rendered view of "base-content.xml" and with 
> real polymorphism it would respond with an html rendered view of 
> "extended-content.xml".

Daniel, you are beating a dead horse. This has been in the original 
design since day 1.

What I'm fighting against, in case you haven't noticed yet, is the 
concept of a blocking having more than one "extends", not on the concept 
of extension alltogether.

>                                   --- o0o ---
> 
> As long as we agree that we want real polymorphism for blocks rather 
> than just shadowing, I can wait with some adaption of MI until other 
> people see that they need it.

Great. Hopefully we can move on now.

>> With that in mind, the complexity increases, if you are composing your 
>> block out of several others (if you have just one block or you just 
>> use ones that provide java components, that is not the case).
>>
>> "explicit" mounting of blocks yields mount collision nightmares: 
>> blocks should be mount implicitly and thru the block manager (sort of 
>> a mount-table on steroids).
> 
> Are you refering to the blocks wiring.xml 
> (http://wiki.apache.org/cocoon/BlocksWiring)?

yes

>> explicit mounting works fine only if you are in control of all the 
>> dependencies, but this cannot be assumed, since blocks should be 
>> downloadable from the outside as well and might bring new dependencies.
> 
> Can you give an example of how this could happen?

You install "Linotype2", is a real block and it requires "Linotype 
Skin", "JCR Repository", "RDF TripleStore". The block manager goes to 
the block library on cocoon.apache.org and finds a list of possible 
blocks that implement those interfaces and that are known to be 
compatible with the version of the block you are now installing.

A dialog between you, the block manager and the block mirrors starts. 
The blocks are downloaded, unpacked, verified, installed and configured.

One of the configurations is the blocks suggest you their default mount 
point (or not, depending if the block is meant for direct public 
exposure or not), but you like your URIs in italian, so you move them.

All this was done without touching a single line in any block, including 
yours.

>> This said, I can't stop the above from happening: even if we have 
>> implicit mounting, you can go ahead and 'remount' it explicitly as you 
>> did above.
>>
>> The fact is that it's not needed if you do the following:
>>
>> <pipeline>
>>   <match pattern="load-user-profile">
>>     ...
>>   </match>
>>
>>   <match pattern="skin/one-special.css">
>>     <read src="styles/css/one-special.css"/>
>>    </match>
>>
>>   <mount-blocks/>
>>
>> </pipline>
> 
> What does "mount-blocks" do?

That's an idea I've been playing with, the use of <mount-blocks/> as the 
mounting equivalent of <xsl:apply-templates/> not sure it's a good idea, 
but allows you to explicitly indicate in what part of the pipeline the 
block mounts happen.

It solves some problems (and makes things more explicit) but I'm still 
not sure it really helps.

>> and the above is the sitemap of MyPortal that extends "Portal" and 
>> it's mount on / and requires "Skin" that is mount on '/skin'.
>>
>> Note however, how if you mount 'Skin' on '/style', the above breaks! 
>> The way I designed it to avoid this problem is:
> 
> As explained above, I don't mount Skin in itself, MyPortal only access 
> Skin through "blocks:skin" and its mount of skin in its own sitemap, so 
> nothing will not break.

Hmmm, I see.

The reason why I don't like this is that if I have things like a skin, 
which might be shared by lots of blocks, mount it in a 'block-relative' 
URL makes it appear as the same information is duplicated all over the 
place, making proxying/caching less efficient.

But sure, it's an approach.

>> MyPortal
>>  - extends Portal
>>  - requires Skin
>>  - mount on "/"
>> -----------------
>>
>>  <pipeline>
>>   <match pattern="load-user-profile">
>>     ...
>>   </match>
>>
>>  </pipeline>
>>
>> MySkin
>>  - extends Skin
>>  - mount on "/styles/"
>> ----------------------
>>
>>  <pipeline>
>>
>>   <match pattern="one-special.css">
>>    <read src="styles/css/one-special.css"/>
>>   </match>
>>
>>  </pipeline>
>>
>> Since <mount> exists and block: will be a Source protocol, it's 
>> impossible to stop you from doing explicit block mounting into your 
>> own block URL space. Note that this scatters the URL control in many 
>> files, instead of centralizing it at the block management level.
> 
> 
> I usually have several applications running under one Cocoon, so for me 
> its not attrcative to handle the "whithin application" url space in a 
> central place, I'll do that in the main sitemap of my application 
> (application block) instead. At the central level I would only mount my 
> applications and possibly some central resources that I want to make 
> available for all applications, without any adaptions or restrictions.
 >
>> I personally won't use it for the above reasons, but if it floats your 
>> boat, go ahead.
> 
> 
> Cool.
> 
>> My point remains: we don't need multiple inheritance of blocks to 
>> achieve what you need!
> 
> 
> As you have avoided commenting on my use cases for the adapted form of 
> MI that I have proposed, it seem to me like a rather far reaching 
> conclusion.
> 
> But we obviously doesn't get anywhere in this discussion. So let's move 
> on and start to actualy design and implement the blocks manager for 
> really polymorphic blocks with single inheritance.

Thank you.

[boy this was exhausting]

-- 
Stefano.