cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: The purpose of the CocoonBean
Date Mon, 20 Oct 2003 18:47:44 GMT
Upayavira wrote:


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


Mime
View raw message