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?
JavaBeans use the set/get/is idiom for naming methods. There were a bunch of sets, making the original a "write only" bean. However, any tool that automatically creates an interface to edit the settings needs both getters and setters. Add to that the hint that isXYZ() is rendered as a checkbox, I ensured that the names made sense.
Instead of getResolveURI() returning true, I use isURIResolved() to make it read better. WIth a tool to automatically generate an interface to edit the CocoonBean, it would be rendered as:
URI Resolved []
It is a question of making it work well with tools that make embedding beans in other projects easier.
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!
One step at a time. I agree that would be best, but I want to integrate first.
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.
Agreed. I will allow you that excersize if you would like.
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.
Correct.
This means that the code in the present ProcessingBean and BatchProcessingBean need some work to move code between them in this respect.
Yep.
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).
:) At this point it should be easy. I need a new EAP license number for IDEA--it makes the job alot easier.
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 figured as much. This is why I separated things the way I did.
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.
Kool. I was hoping not to raise too many alarms.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin