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
message.
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
"oneObject.setStuff(anotherObject.getMoreStuff(theThirdObject.getLotsaStuff(
))".
Cheers,
Runar
-----Original Message-----
From: Arved Sandstrom
To: [EMAIL PROTECTED]
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
to
>Java 1.2 and the new J2EE 1.3 javax.xml packages? I find the current
>architecture rather inflexible (procedural programming practices
abounds).
OK, you've got me a little bit curious. :-) What do you consider to be
an
example of "bad" procedural programming in FOP? I'm sure we have plenty
of
it; I'm just wondering where you think it is obscuring the
implementation
and _should_, rather than _could_, be replaced by pure OO?
I don't think that the processing of XSL FO is necessarily or naturally
best
represented as something to be solved by pure OO. My gut feeling is that
the
nicest solution is a hybrid - some aspects (such as properties) are
handled
through OO, and the actual formatting is handled procedurally. Not that
FOP
does it like that, that's just my personal opinion. I'm sure that one
can
come up with really nice pure-OO solutions, but I'm just as sure that
very
nice hybrid or pure-procedural solutions are possible, too.
Also, exactly what do you mean by API? That means almost anything these
days
(usually it means "we're not particularly interested in doing the work
of
writing an implementation, but we'd like to hijack the technology". As
in,
Sun defines all the APIs for J2EE, but they have yet to write a
reference
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
FOP,
configuring FOP, and plugging in different renderers, yes, we already
pretty
much have an API. Although it's always open for improvement.
Regards,
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]
