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.
Features -------- 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 sitemap. Here's a sample of how the config file could look. <bean xmlns="http://xml.apache.org/cocoon/something-1.0";> <!-- DEFINITIONS OF DESTINATION COMPONENTS --> <destinations default="ftp"> <destination name="ftp" protocol-prefix="ftp://"; class="org.apache.cocoon.destination.FTPDestination"/> <destination name="http" protocol-prefix="http://"; class="org.apache.cocoon.destination.HTTPDestination"/> <destination name="email" protocol-prefix="mailto:"; class="org.apache.cocoon.destination.EmailDestination"/> </destinations> <!-- DEFINITION OF LOGGING OPTIONS --> <logging log-kit="logkit name" logger="logger" log- level="ERROR"/> <!-- DEFINITION OF SITES AVAILABLE FOR GENERATION --> <site name="avalo" threaded="yes"> <page follow-links="yes" confirm-extension="yes"> <source>/avalo/index.html</source> <destination uri="ftp://user:[EMAIL PROTECTED]/folder/> </page> <page follow-links="no" confirm-extension="no"> <source>/avalo/avalo.html</source> <destination uri="ftp://user:[EMAIL PROTECTED]/folder/> </page> </site> <site name="vajras"> <page follow-links="yes" confirm-extension="no"> <source>/vajras/index.html</source> <destination uri="ftp://user:[EMAIL PROTECTED]/folder/> </page> </site> </bean> I look forward to any comments you might have. Regards, Upayavira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
