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.
