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.
