Setting up the Cocoon Bean for 2.2

[Berin Loritsch <bl...@apache.org>]

The CocoonBean concept should be to set all the options available for Cocoon one
at a time--providing one testable interface for both the Servlet environement
and the command line.  It does not make any assumptions about the Environment or
anything along those lines.

Does anyone have a complete list of options for the bean?  It seems the Bean
is handling multiple concerns.  I would like to simplify it to JUST be the
config options, and have another object take care of the specifics.

It would have the initialize() and dispose() methods, but other than that, it
would be a typical JavaBean interface.  I think that works best.

The Target and associated methods are somewhat confusing to me.

-- 

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

Re: Setting up the Cocoon Bean for 2.2

[Upayavira <uv...@upaya.co.uk>]

Berin Loritsch wrote:

> The CocoonBean concept should be to set all the options available for 
> Cocoon one
> at a time--providing one testable interface for both the Servlet 
> environement
> and the command line.  It does not make any assumptions about the 
> Environment or
> anything along those lines.

This is not how the CocoonBean has at present been conceived. Its 
purpose is to allow the use of Cocoon to generate pages/sites 
programmatically without having to know about the internals of Cocoon. 
It has two clients at present - Main.java (the CLI) and CocoonTask.java 
(an Ant task).

> Does anyone have a complete list of options for the bean?  

There is no list specifically for the bean, but you can get an idea of 
what it does from the CLI docs and from the code itself.

> It seems the Bean
> is handling multiple concerns.  I would like to simplify it to JUST be 
> the
> config options, and have another object take care of the specifics.

Can you say what you think those concerns are?

> It would have the initialize() and dispose() methods, but other than 
> that, it
> would be a typical JavaBean interface.  I think that works best.
>
> The Target and associated methods are somewhat confusing to me. 

The significant classes that are a part of this suite are:

Main.java: Command line parameter handler which instantiates a 
CocoonBean and uses it to render sites
CocoonTask.java: Does the same but as an Ant task
BeanConfigurator.java: Parses a DOM document containing configuration 
info for the CocoonBean.
CocoonBean.java: Along with the Crawler class, handles generation of 
multiple pages and crawling a site
Crawler.java: Remembers which pages have/haven't been generated, and 
provides an Iterator to the CocoonBean.
CocoonWrapper.java: Creates and initialises a Cocoon object. Creates 
CommandLine environments and offers basic methods for getting content 
from Cocoon and handing that back to an OutputStream.
BeanListener.java: Interface providing a method for a CocoonBean to 
report back on progress to a caller
Target.java: Handles 'URI arithmetic' - how a URI for a Cocoon page is 
converted into a URI for a file to be written to disk.

In a conversation with Vadim at the GetTogether, he talked about how the 
servlet should use the Bean, which sounds like what you are saying.

I have tended to stear clear of 'core' things that I don't undersand too 
well, such as the CocoonWrapper.initialise()  method. I just left it as 
it was.

What do you think are the multiple concerns that the CocoonBean handles?

I wonder if the bean that you are talking about is really the same thing 
as the CocoonBean as it stands. It sounds to me like the current 
CocoonBean should be using the thing that you're talking about, as does 
the servlet.

The aim I've had in working on the CocoonBean is to provide a simple 
programmatic interface to page generation using the Cocoon engine, in a 
way that does not expose Avalon (or Environments for that matter) to the 
outside.

Regards, Upayavira