On Friday, Oct 10, 2003, at 11:04 Europe/Rome, Stephan Michels wrote:
On Thu, 9 Oct 2003, Stefano Mazzocchi wrote:
On Wednesday, Oct 8, 2003, at 04:50 Europe/Rome, Geoff Howard wrote:
Stefano Mazzocchi wrote:
I have updated the block design documents on the wiki. Changes were:
...
A few things are left to decide: 1) the block metadata information in the block.xml file see http://wiki.cocoondev.org/Wiki.jsp?page=BlocksCob 2) how blocks expose classloading to other blocks - o - Descriptive Block metadata -------------------------- The descriptive block metadata that we currently include is: <name>***</name> <description href="...">***</description> <license href="..."/>***</license> <author href="...">***</author>
+1
Andreas suggested version number which is really handled already in the block id and release date. I think a date though may be a useful additional piece of info.
Good point.
IMHO, I would try first a solution, which doesn't introduce a new descriptor.
like what?
In a know german XML magazin, Cocoon was descriped a configuration hell, and as a anti pattern using XML as configuration format.
yeah, we agree about the configuration hell, but this is because we expose too much of things that people should never touch.
So my proposal would be to start small, and if there isn't a way to come forward with the current possibilities, then we could introduce a new descriptor file beside cocoon.xconf/sitemap.xmap/web.xml etc.
you didn't get it: the is the *block* descriptor. each block needs one. I see no way to go without one.
Exposing classes
----------------
Stephen proposed to separate the classes to expose in a different jar
and expose that. I like this. It's simple and effective.
But instead of declaring classloaders or classpaths in the blocks, I
propose to extend the block FS layout so that we have
for individual classes and resources:
/classes
/classes/public
/classes/private
for jars:
/lib
/lib/public
/lib/private
Hmmm. That is quite different than what one would expect from the WAR
paradigm, no? Would
COB-INF/[classes|lib] COB-INF/public/[classes|lib]
or
COB-INF/private/[classes|lib] COB-INF/public/[classes|lib]
be any better?
Could you please explain, why we need to separate the classes and lib into
private and public. For the developers POV, it will make the development
more complicated, and doesn't see any benefit.
to better isolate classloader and the contracts that are exposed by the block. make development more complicated but forces people to think of application contracts that can be later reused as global behaviors.
think of it as a generalization of a collection of interfaces and data structures that are passed around. like JAXP+Xerces jaxp is public, xerces should not be, otherwise the public methods of the xerces classes can be hooked up and later broken if a new implementation of JAXP comes around.
also reduces the potential problems with hot deployment for classloading dependencies
-- Stefano.
