Pier Fumagalli wrote:
<SNIP/>
If on the other hand we separate entirely components and java code from
blocks, the implementation becomes _much_ more easy...
My idea would be that a block (for example, our ForrestSkin
implementation) _requires_ a component (not a block) that performs XSLT
transformations.
Requiring this, it will expose (for example) a "Virtual Transformer" called "document2html" which will be implemented as XSLT Transformer + document2html.xslt.
Another skin for forrest could (at the same time), implement the same
interface and provide the same "document2html" transformer by requiring
the STX transformer and "joining it up" with "document2html.stx".
From outside, the two blocks _both_ provide a transformer, which does exactly the same job, but rely on the component manager underneath to solve the class loading problem of providing a component with a given role, add their value to it (the XSLT, STX, ... stylesheet) and expose it to the users of the implemented interface.
And this frees up the blocks implementation from the underlying component management, java, class loaders and so on... I feel this a lot more cleaner in terms of separating the concerns of cocoon and blocks versus the concerns of the Java platform and its classloading cumbersomeness...
Where do the components life and where are they defined?
I'm not sure if I totally understood everything discusses so far, but imho we need some versioning: we recently had the following problem. In a cocoon application we used Hibernate that requires the version 1.4.x of the asm jar file. With Cocoon 2.1.7 we ship version 1.5.x which causes some method not found exceptions inside hibernate :( Ok, now we could lean back and blame the developers of asm creating incompatible versions, but I think this is a general issue. What if one component requires version 2.x of a third party lib while another one requires a 1.x version. Etc. Fortunately, we could solve this problem in our solution by just using asm 1.4.x as we don't need the BSF block.
Ok, long story, short question: do we plan to support such scenaries with real blocks? I really hope so :)
Absolutely we do, but not in the very first phase of blocks. Blocks, in my view, addess separate concerns from the classes they require for the implementation of the virtual sitemap components that they expose to other blocks.
At the beginning, and that's what we agreed a couple of months ago, we completely disregard all those classloading issues by implementing the block paradigms without touching those, as those concerns will have to be addressed by the component manager underlying the whole systems.
But re-adding libraries and classes into the pictures, tells us that we do _now_ have to think about the class-loading issues, and multiple versions of same interfaces, multiple versions of classes and so on...
Making the whole process a load more complicated from the outset, and when (IMVHO) class-loading and cocoon block deployments are two completely separate concerns...
Pier
