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
