RE: images from a servlet?
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]
RE: images from a servlet?
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]
images from a servlet?
Hi. I'm able to get images in my pdf output when running fop from the command line, but when I embed it in a servlet (used the example in the FAQ), no images appear. There is no exception or anything like that. The images simply don't show up. Is there any known issue with certain JVMs or something that might be causing images not to appear? I'm running WebSphere 3.5 with Java 1.2.2. The FO file I'm trying is the images.fo from the examples dir. 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). Thanks, Runar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: images from a servlet?
Hi Runar, Are you using a relative url to reference the image? Remember that Fop will use the current dir of the servlet engine's VM, not the directory of your source fo. This will not generate an exception, but a warning (I believe) - does the system.out log have anything to say for itself? Or is Fop's message generation set to NONE? HTH, JT -Original Message- From: Runar Bjarnason [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 02, 2001 11:55 AM To: '[EMAIL PROTECTED]' Subject: images from a servlet? Hi. I'm able to get images in my pdf output when running fop from the command line, but when I embed it in a servlet (used the example in the FAQ), no images appear. There is no exception or anything like that. The images simply don't show up. Is there any known issue with certain JVMs or something that might be causing images not to appear? I'm running WebSphere 3.5 with Java 1.2.2. The FO file I'm trying is the images.fo from the examples dir. 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). Thanks, Runar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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]
