cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] composition vs. inheritance in blocks
Date Sun, 03 Apr 2005 12:19:37 GMT
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"; }


Extended e = new Extended();

will obviously print "Extended".



will print "I'm Extended" rather than "I'm Base".

                                   --- o0o ---

Translating this to blocks we get:

BaseBlock Sitemap

   <match pattern="content">
     <read src="base-content.xml"/>

   <match pattern="view">
     <generate src="blocks:/content"/>
     <transform src="content2html.xsl"/>

ExtendedBlock Sitemap

ExtendedBlock extends BaseBlock

   <match pattern="content">
     <read src="extended-content.xml"/>

Saying that we mount ExtendedBlock at "/" then


obviuosly will respond with the content of "extended-content.xml"

with mere shadowing


would respond with an html rendered view of "base-content.xml" and with 
real polymorphism it would respond with an html rendered view of 

                                   --- 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.

> 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 

> 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?

> 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?

> 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.

> 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.


> 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 

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.


View raw message