Hi,

Here are my thoughts.

For the sake of convenience you should derive your Generator from
"AbstractGenerator" (or any of its descendants). The protected field
"contentHandler" lets you send SAX events down the pipeline. The protected
field "source" represents the URI according to the mapping defined in the
Sitemap. You can use the protected field "resolver" to resolve the source
into a SAX InputSource.

Here's the code from my own DocumentGenerator class. This class generates a
simple document structure from a text file using a DocumentReader(an
XMLReader implementation that converts a text file into a stream of SAX
events). The DocumentGenerator is paired with a DocumentSerializer which can
produce a Palm PDB file from SAX events.

-----------------------------------------------
package distantcord.palm;

import distantcord.palm.DocumentReader;
import java.io.IOException;
import org.apache.cocoon.ProcessingException;
import org.apache.cocoon.ResourceNotFoundException;
import org.apache.cocoon.generation.AbstractGenerator;
import org.xml.sax.InputSource;
import org.xml.sax.SAXException;

public class DocumentGenerator extends AbstractGenerator {

    public void generate() throws IOException, SAXException,
            ProcessingException {
        // Obtain a SAX InputSource.
        InputSource inp = resolver.resolve(source).getInputSource();
        // Create a DocumentReader. This generates ContentHandler events.
        DocumentReader docReader = new DocumentReader();
        // Set the ContentHandler.
        docReader.setContentHandler(contentHandler);
        // Parse the InputSource. This starts off the stream of SAX events.
        docReader.parse(inp);
    }

}
-----------------------------------------------

The purpose of the class is beside the point. What I want to say is that you
should separate the parsing logic (the XMLReader implementation ) from the
Generator. This way you can reuse the parser in a standalone SAX
application. In fact, I think you could make a SAX-based Generator class
generic so that you could supply the class name of your XMLReader
implementation as an initialization parameter. You would then use
Class.newInstance() or another reflection mechanism to instantiate the class
at runtime.

There is no need to use a Transformer to convert your SAX events into an XML
stream first. You can send the SAX events down the pipeline immediately.

The mapping in your sitemap is wrong I think. The wildcard pattern must be
specified in <map:match> like this:

<map:match pattern="**.txt">
     <map:generate type="poemtxt" src="poemtxt/{1}.txt"/>
     <map:transform type="xslt" src="stylesheets/poemtxt/xpoem-html.xsl"/>
     <map:serialize type="html"/>
</map:match>


Regards
-Laurens

----- Original Message -----
From: "Bob Phillips" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, October 21, 2001 9:00 PM
Subject: cocoon2 generator implementation query


> I have been looking at making a cocoon2 generator and would be
> interested in advice or criticism about my strategy.



---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Reply via email to