cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: The purpose of the CocoonBean
Date Mon, 20 Oct 2003 14:01:38 GMT
Upayavira wrote:

> I note from commit messages that Berin has completely changed the 
> purpose of the CocoonBean. The CocoonBean is a published (if not 
> entirely stable) interface, and therefore I think this needs some 
> discussion before it can be changed significantly.
> It seems to me that Berin is trying to create a bean to have a clean 
> access to the Cocoon class, which seems fair enough - I've got no 
> objection to that.

What I am doing is taking the purpose of the CocoonBean, and making it
more clear.  Proper separation of concerns, adding functionality in la

> However, it is a completely different thing to the current bean, which 
> is much more geared around offering a non-Avalon interface to Cocoon for 
> inclusion in other java code.

Actually, it is not too far different from the current bean.  First, it is
more truly a bean.  Setters AND getters for every configuration option.
Secondly, it is split into three different beans, each extending the other.
The first bean is purely the clean access to setting up the core options
for the Cocon environment with the ability to start and stop the system.

On top of that, we have a ProcessingBean (if my memory serves me for the
actual use of the system).  That processing bean takes care of processing
a request or compiling the generated classes in the system.  Lastly, we
have the BatchProcessingBean which is more like the previous CocoonBean.
The BatchProcessingBean provides the support to run a number of URIs through
the system, which is what you are probably referring to.

The old CocoonBean comes short in this respect because it assumes that
everything will do batch processing.  That is not true.  For example,
the Servlet environment does not do that.  It might use the ProcessingBean,
or it might use the new CocoonBEan only.

I think it is important when we write things along those lines that we
make no assumptions for any particular environment--and we provide extra
functionality with subclasses as necessary.

> I think that the CocoonBean should be left in its place, and that 
> Berin's bean should be placed somewhere else (and named suitably so as 
> not to cause user confusion when people go hunting for the CocoonBean).
> What do others think?

:/  I think we should just have ONE bean that can work in any environment,
including the Servlet environment (which the older bean did not do very well).
Having two beans would lead to confusion.


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

View raw message