cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [Kernel22] How to develop a component?
Date Wed, 07 Apr 2004 09:33:50 GMT
Nicola Ken Barozzi wrote:
> 
> Carsten Ziegeler wrote:
> ...
> > To be honest, I still don't buy the classloader problem theory. I'm 
> > just saying that we should try to support interfaces like 
> Configurable etc.
> 
> For Cocoon blocks or for other components?
> 
For all components :) A block might contain custom components and for
these components I want to support the Avalon interfaces.

> ...
> > And the dependency is very minimal. It's just a dependency 
> against the 
> > avalon framework api version 4.1.5 - a released version. 
> There is no 
> > need in following the development of Avalon.
> 
> The issue is not so technical as it's of indipendence from 
> something that, in the good and the bad, has not helped 
> Cocoon be built by Gump for ages now.
> 
> What I don't understand, is the portability of *which* Avalon 
> components you don't want to loose. Business logic used as 
> Avalon components? 

Yes, for example. Or components for special purposes that can
be used outside of Cocoon as well.


> I don't see why not retain this 
> possibility. 
Exactly my point :) But the current idea of blocks is to only retain
this possibility inside a sandbox which means it can't be used "inside"
blocks. So if I develop my app as a block, I can't use these components
inside my app!


> The question is just about the *Cocoon* 
> components, that are not portable anyway between Cocoon'ECM 
> and, for example, Merlin.
If we would only talk about *Cocoon* components, than sure, we don't
need to support the Avalon interfaces there. But as far as I'm understanding
it, we are talking about all components.

Carsten


Mime
View raw message