Hi, Runar

Alright, these are the kind of comments I was looking for. I don't 
necessarily disagree with some of them, particularly as it relates to the 

Sorry if I was a bit irritable in my last reply. I've spent literally months 
wrestling with customer and technical support for a large (and possibly 
previously identified) company, concerning bugs in an _implementation_. Of 
course this same company hemorrhages APIs - evidently _that_ they are pretty 
good at. Yesterday was another long day along those same lines, and I got a 
bit heated when a few of my buttons got pushed a bit. Sorry.

Arved Sandstrom

At 01:30 AM 8/2/01 -0500, Runar Bjarnason wrote:
>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]
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]

Reply via email to