Ok, I admit I haven't been looking at the source code very long, but I've
been somewhat frustrated with some of the things I'm trying to accomplish
with FOP. For instance, the Driver class only has void methods, which does
nothing for its pluggability.

When I say "API that conforms to...", I understand that FOP already has an
API, but I'd like to see a little less rigid interface on this thing.

For instance, it would be nice to be able to have the driver return the FO
tree, so we could persist it for later use without having to rebuild from
the file. Also, I'd like to be able to pass in a Reader or an InputStream
for rendering and get an OutputStream or a Writer back. Stuff like that.

Also, I tried passing an InputSource object that I got from a
TransformerFactory (J2EE 1.3), but couldn't without passing it an XMLReader.
Well, I tried getting the XMLReader from the factory as well, but FOP threw
a NullPointerException at it. I'll send the exact code in a separate

One argument for OO and against the procedural route is that procedural code
is not as easily generated from XML. Code generation is generally more fluid
and natural when dealing with OO stuff. XSL templates lend themselves very
well to this (as per Cocoon), and its ever so convenient to be able to
generate a series of calls that "pipe" to each other like


-----Original Message-----
From: Arved Sandstrom
Sent: 8/1/2001 10:12 PM
Subject: Re: images from a servlet?

At 09:24 PM 8/1/01 -0500, Runar Bjarnason wrote:
>By the way, is there an effort underway to make a FOP API that conforms
>Java 1.2 and the new J2EE 1.3 javax.xml packages? I find the current
>architecture rather inflexible (procedural programming practices

OK, you've got me a little bit curious. :-) What do you consider to be
example of "bad" procedural programming in FOP? I'm sure we have plenty
it; I'm just wondering where you think it is obscuring the
and _should_, rather than _could_, be replaced by pure OO?

I don't think that the processing of XSL FO is necessarily or naturally
represented as something to be solved by pure OO. My gut feeling is that
nicest solution is a hybrid - some aspects (such as properties) are
through OO, and the actual formatting is handled procedurally. Not that
does it like that, that's just my personal opinion. I'm sure that one
come up with really nice pure-OO solutions, but I'm just as sure that
nice hybrid or pure-procedural solutions are possible, too.

Also, exactly what do you mean by API? That means almost anything these
(usually it means "we're not particularly interested in doing the work
writing an implementation, but we'd like to hijack the technology". As
Sun defines all the APIs for J2EE, but they have yet to write a
implementation that conforms or works...even a production implementation
for that matter, but I'll name no names). If you 
mean are we interested in well-known, stable interfaces for invoking
configuring FOP, and plugging in different renderers, yes, we already
much have an API. Although it's always open for improvement.

Arved Sandstrom

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia

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

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

Reply via email to