cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: [RT] Sitemap inheritance
Date Sun, 26 Oct 2003 20:22:22 GMT
Sylvain Wallez wrote:
> Gianugo Rabellino wrote:
>> Sylvain Wallez wrote:
รน>>>> To me, having inheritance only in blocks look a bit like saying that
>>>> you can extend only from java.*, while user classes have to be 
>>>> always final. It's rough and inaccurate, but can you see my point?
>>> Mmmh... by "java.*", I understand that you consider that only the 
>>> Cocoon team will define block interfaces. But everybody can define 
>>> its own private block interface and its implementations and do 
>>> whatever it wants with it. This only requires to have a local block 
>>> librarian for those private blocks that is queried before the main 
>>> Cocoon librarian. This is similar to setting up a classpath that will 
>>> add your own classes to those in the JRE.
>> Fair enough: I will be able to provide my own block, and so will you 
>> and possibly everyone who reads this mail. But the problem is that 
>> only people with "block librarian" skills will be able to use Cocoon, 
>> if everything is packaged as a block. I'm afraid that this would just 
>> scare people away, even before they can understand the huge benefit of 
>> blocks.
> Sorry Gianugo, I meant no offense, and I see your point now. 

No problem, I didn't see or take any offense in your reply. :-)

> The concern 
> is actually about the ease of use of what we can call "local blocks".
> I had talks with Stefano about the need to have blocks non-archive 
> blocks on the local filesystem for roundtrip time during development 
> (you don't want to build a cob file to test each time you change a 
> line). 

Yes, definitely you don't.

> We can extend this behaviour to local blocks that allow 
> "non-librarian-aware" people to use the blocks mechanisms without having 
> to run a librarian server, package their blocks and all the associated 
> stuff.
> Implementation-wise, this may mean that the block deployer can rely not 
> only on a remote librarian server, but also on a local "blockpath" that 
> is queried first before the remote server.

If this means "shielding" users from the need of having a block, I 
completely rest my case. But we need to have backward compatibility to 
what we have now: unpack war (or go to build/webapp) and work from 
there. Anything more complicated, no matter what the advantages are, 
would just be overkill to the average user.


Gianugo Rabellino
Pro-netics s.r.l. -
Orixo, the XML business alliance -
     (Now blogging at:

View raw message