cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: Directory structure of blocks
Date Wed, 13 Apr 2005 13:14:57 GMT
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 :)


Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Mime
View raw message