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. 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). 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.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
