cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Upayavira" <>
Subject [Proposal] Cocoon Bean Utility
Date Tue, 14 Jan 2003 22:17:14 GMT
Dear All,

Now that I've created a Cocoon bean, I need to create an 
application to drive it. I would like to produce something 
reasonably generic, that might be of use to others - hence 
this proposal. What I detail below is what I have thought of 
so far, but I would very much appreciate comments about it 
before I get started.

My proposal is for a generic application that will give access 
to the bean, and can be accessed either via the command line 
or as a Cocoon Generator.

This application will be configurable via an XML file 
(detailed below). This file will allow one instance of the 
application to manage more than one site.

It will be possible to run the command line application once 
for a single pass at site generation, or to leave it running, 
in which case it will be possible to trigger it to regenerate 
a specific site.

At present I am not sure of the best triggering mechanisms, 
however I will probably implement a 'file drop' trigger, where 
a file created in a predefined folder will trigger the 
generation of a site (as specified in the dropped file).

HTTP based triggering can be achieved through the 
BeanGenerator. Simply passing a parameter into the 
BeanGenerator, which is itself running in a separate Cocoon 
instance in a servlet engine, will trigger the regeneration of 
a site.

Generator triggering can be either synchronous or 
asynchronous, where synchronous triggering waits until pages 
have been generated, returning details of the generated pages 
to the user, and asynchronous triggering returns as soon as 
page generation has started, and continues page generation in 
the background. [I am assuming I can work out how to do this.]

At present I imagine my BeanGenerator to be only capable of 
handling a single thread at one time, returning an error if 
the generator is called when another instance is processing a 
site. However, it would be good to make it handle simultaneous 
generation of separate sites.

XML Configuration File

The configuration file allows for the specification of pages, 
identified by Cocoon URIs, grouped into sites.

All of the configuration available to the existing Command 
Line will be available through this configuration file.

Parameters such as 'follow-links' or 'check-extensions' will 
be configurable against the root element, against a site, or 
against a specific page.

In order to make the application as extensible as possible, a 
Destinations section at the beginning of the file will allow 
the user to specify new Destination classes, much like one can 
declare new sitemap components at the beginning of the 

Here's a sample of how the config file could look.

<bean xmlns="">

  <destinations default="ftp">
    <destination name="ftp" protocol-prefix="ftp://" 
    <destination name="http" protocol-prefix="http://" 
    <destination name="email" protocol-prefix="mailto:" 
  <logging log-kit="logkit name" logger="logger" log-

  <site name="avalo" threaded="yes">
    <page follow-links="yes" confirm-extension="yes">

    <page follow-links="no" confirm-extension="no">

  <site name="vajras">
    <page follow-links="yes" confirm-extension="no">


I look forward to any comments you might have.

Regards, Upayavira

To unsubscribe, e-mail:
For additional commands, email:

View raw message