cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] composition vs. inheritance in blocks
Date Fri, 01 Apr 2005 18:02:00 GMT
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://"/>

?

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 ?

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.

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

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>

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:

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

-- 
Stefano.


Mime
View raw message