cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jestel, Roger B. (LNG-ALB)" <>
Subject Is this abuse of the SourceWritingTransformer and clever sitemap tricks?
Date Wed, 21 May 2003 14:07:05 GMT
I have been lurking for a while, and am evaluating Cocoon for use in a
project that needs a conversion engine.  Our project does not really fit
with how Cocoon normally seems to be used since it has nothing to do with on
or offline generation of websites.
I have prototyped this, and it seems OK, but before going too much farther,
I was hoping for some input on if I am doing something that really shouldn't
be done with Cocoon.  I am somewhat concerned because of this, which showed
up in a google search from Steven Noels weblog
<> ).  
>>>   Ah - a first rant. [content omitted..] I'm very afraid to see lots of
people using the 
>>>  SourceWritingTransformer and clever sitemap tricks underneath their
home-brewn CMS. 
I am not writing a CMS, but am planning on using a (modifed)
SourceWritingTransformer and arguably clever sitemap tricks...
Description of system:
Users create products consisting of collections of different types of
(mostly xml) input files, and provide metadata indicating how the files need
to be treated to produce a product.  This is done through an existing set of
I'd like to use Cocoon to process these products, having the pipelines use
the metadata to determine what to do with the data files.  The output
products consist of a series of reports and converted files in a different
directory structure.  This is kind of similar to Forrest, but I would like
to simplify the configuration by keeping all of the processing logic within
Cocoon by making extensive use of aggregation and a
FileWritingTransformer(stripped down, sax based sourcewriting transformer),
and using the output stream not for content, but for a status reporting
summary of the pipelines that ran.
The cocoon bean would be used to call a product type specific pipeline (i.e.
productType/processEntireProduct), and will add an object representing all
of the product metadata(basically a fileset) to the object model for use by
each pipeline. 
The main pipeline would be something like:
<map:match pattern="processEntireProduct" >
<map:aggregate element="product" prefix="fce" >
<map:part src="cocoon:/runInputReport1" element="reportRun"></map:part>
<map:part src="cocoon:/runInputReport2" element="reportRun"></map:part>
<map:part src="cocoon:/processParseableContent"
<map:part src="cocoon:/processGraphics"
<map:part src="cocoon:/processTextContent" element="contentProcessed"
<map:transformer type="upatefileset"/>
<map:match >
each called pipeline would start with a FileSet generator, which uses the
product metadata to produce an xml stream corresponding to all of the files
that need to be processed (similar to the directory generator, but with more
information for each file).  The pipeline would use the metadata to filter
the file list and add cocoon:/...   cinclude markup to each file in the
fileset that needs processing, call the cinclude transformer which would
call the pipelines to do the actual conversions, aggregate or segment the
files as needed and save all of the outputs to disk.  The result stream
would end up containing markup indicating what files had been written to
disk, any errors that occurred, reports that have been generated, etc, but
all the content will have been written out to disk already.
I've had to extend the CIncludeTransformer to catch errors and output a
NotifyingBuilder stream rather than failing, and use the ContentAggregator
patch to do the same, but other than that, this seems to be a feasible
approach, and keeps all of the processing logic in Cocoon rather than adding
an outside program to generate the list of uris/paramters that need to be
called for each product.
I think Cocoon is an amazing product and would like to use it for our
content conversion, but was hoping to make sure this is a reasonable
approach before selling it to others on my team.
Thanks to Upayavira et al for all the recent work on the Cocoon bean/CLI,
which has made cocoon a much better option for offline work.  

View raw message