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
