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
Okay.
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 enough!
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 respect.
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
