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
interface.
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.
Regards,
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
>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]
>
>
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]
