cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Finishing the first phase of block design
Date Fri, 10 Oct 2003 11:15:53 GMT

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
>>>>  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


View raw message