cocoon-dev mailing list archives

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

> 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. 

Can you explain a little? What makes something 'truly' a bean?

> 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.

Now having seen what you have done (by adding these other beans), I can 
understand it more.

In fact, looking at the code now in the ProcessingBean (which it seems 
is a pretty straight copy of CocoonWrapper), I think you didn't go far 

For example, the ProcessingBean should be independent of Environment, in 
my view, and should provide methods for generating pages from a Cocoon 
instance, but those methods must be provided with an environment in 
order to do so.

Then the BatchProcessingBean will pass into the ProcessingBean a 
BatchProcessingEnvironment (or subclass, such as 
LinkSamplingEnvironment), because BatchProcessingBean is much more tied 
to a specific environment.

This means that the code in the present ProcessingBean and 
BatchProcessingBean need some work to move code between them in this 

> 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.

This is the sort of direction I was heading in slowly (with Vadim's 
guidance). Splitting the bean into CocoonBean and CocoonWrapper went 
part of the way there, but there was always a question about why the 
servlet didn't use the bean (which Vadim has always been suggesting it 
should, but scared me too much to go near).

The assumption that everything is about batch processing comes from its 
history (the original CLI), but it has never been viewed as purely batch 
processing, at least in terms of where it has been heading.

> 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.

You are effectively proposing a class to sit under the two I've worked 
on, which is independent of Environment, which is fair enough.

>> 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.

All I was suggesting was a matter of naming. I now see, having seen your 
ProcessingBean and BatchProcessingBean, that your scheme does make 
sense, and is not as drastic as I first perceived.

This will mean a change in a public interface, but this is 2.2, so I'm 
fine with that.

I am therefore happy to follow your proposal.

Regards, Upayavira

View raw message