From: "Keiron Liddle" <[EMAIL PROTECTED]>

> At this stage of the design very few core problems can be solved in
> isolation. So if someone wants to implement for example keeps or a colour
> property, it has an impact on almost everything else in the layout.
> So what is needed and what will make all the difference right now is more
> involvement on things like the website, FAQ, configuration, external
> interfaces, image handling etc.

Ok, I think I get the picture :-)
Thanks Keiron, you are clear as always.

For the website, as I already outlined, there is an effort going on called
Forrest ([EMAIL PROTECTED]) that will make the site
easier to maintain and full of new features.
I'm keeping a build system that uses Ant and Cocoon on, that is currently used by Forrest itself, Jakarta
POI and others. Maybe it could help a bit with the build and the
documentation generation process, but it's just a hint. If you have a spare
minute, take a look at it and see if it can help. Its force comes from tha
fact that all the projects that use it enhance their build and tools one

What "bugs" me in FOP currently (the famous itch to scratch ;-) , is what
drives the whole process itself. Configuration, URI resolving, logging, and
so on. The infrastructure.
I'm not so much into FOP mechanics to help the DOM2SAX transition right now,
but as for the contour, I have a couple of ideas.

As I've hinted in past mails, I think that the fastest, I repeat *fastest*,
not necessarily the best, way of doing this transition is to use Cocoon.
Cocoon2 is bigger than is needed by FOP, but with some minor changes, IMO
it's just the right container for FOP.

 FOP + Cocoon = FOPoon

Why Cocoon?

Well, I start all the reasoning by acknowledging that the FOP community
wants to reuse stuff done by other projects, and that Avalon is generally
regarded as a good solution.

Avalon is like an _onion_:

 the framework
 the simple implementation (Excalibur)
 the full fledged server (Phoenix with Cornerstone blocks)

If we want to reuse as much as possible, and advance automatically in speed
and features with the advancements of Avalon, we need to use more than the
mere framework, which is basically a collection of interfaces and hints for
good programming practices. Since Phoenix is plainly overkill, what remains
is Excalibur.

This places Avalon between Excalibur and Phoenix, and it makes it clear that
in the future FOP could be packaged as a Block.

Now, what features of Avalon framework+Excalibur does FOP need?
- URI resolving
- xml processing
- pipelining
- component managers
- pools
- lifecycle handling
- configuration
- generic storage
- other things I don't think of ATM

There is a project on Apache that uses these Excalibur parts to make a
pipeline, and that project is Cocoon.

There are some drawbacks though:
- overkill?
- difficult to use?

As for Cocoon being overkill, it may stand if we use Cocoon as-is.
It has parts that FOP doesn't need, but they can be removed.
A cleaned Cocoon can give FOP only what it needs, and basically all that it
needs as infrastructure.
One thing that should be changed is the sitemap; Fop needs a very simple
sitemap, and pligging in a simple new version is easy, once the system is
working. For those who don't know, a sitemap is an xml file that specifies
how to handle the XML steps of the pipeline.

If you don't know Cocoon yet, please take a look at the Cocoon site at , and I'll be glad to answer your questions.

FOP can be made as a Cocoon pipeline:

The Generation is already present in Cocoon: it parses the xml and spits out
SAX events. Total reuse here.
The Serialization is the Rendering phase: it accepts the SAX events and
spits out the resulting stream: this is easy to do: we just need to make a
DOM out of it and use one of the FOP renderers or even iText.
The middle part is what happens in between. There are transformations of the
XML that are the meat of FOP, and for now we can use the DOM code there is.

Here are the interfaces for a Transformer and a Serializer:

public interface Transformer extends XMLPipe, SitemapModelComponent {

public interface Serializer extends XMLConsumer, SitemapOutputComponent {

    String ROLE = "org.apache.cocoon.serialization.Serializer";


public interface SitemapModelComponent extends Component {
     * Set the <code>SourceResolver</code>, objectModel <code>Map</code>,
     * the source and sitemap <code>Parameters</code> used to process the
    void setup(SourceResolver resolver, Map objectModel, String src,
Parameters par) throws ProcessingException,
        SAXException, IOException;

public interface SitemapOutputComponent extends Component {
     * Set the <code>OutputStream</code> where the requested resource should
     * be serialized.
    void setOutputStream(OutputStream out) throws IOException;

     * Get the mime-type of the output of this <code>Component</code>.
    String getMimeType();

     * Test if the component wants to set the content length
    boolean shouldSetContentLength();

public interface XMLConsumer extends ContentHandler, LexicalHandler {

public interface XMLPipe extends XMLConsumer, XMLProducer {}

public interface XMLProducer {

     * Set the <code>XMLConsumer</code> that will receive XML data.
    void setConsumer(XMLConsumer consumer);

As you can see, it's pretty straightforward.
Cocoon also makes all Avalon markers available: if you mark it as Poolable,
it gets pooled, LogEnabled, it gets logging, Configurable, it gets a
Configuration, and so on.

When this is in place, all the infrastructure is there, and we can
concentrate on the real FOP code.

Ok, fire at will, I have an asbestos suit on ;-)

Nicola Ken Barozzi                   [EMAIL PROTECTED]
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)

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

Reply via email to