struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juan Ara <>
Subject Re: [SAF2] Tossing an idea around: PDFResult
Date Tue, 06 Jun 2006 06:39:24 GMT
Hi all, I'm not as active as most of you, maybe I'm too new too 
dev-list, just learning the way to post and that stuff.
I don't pretend to merchandise anything here, just giving clues hoping 
they are usefull ;)

> Yes, I agree, going the route of FOP, or something similar, certainly 
> implies a more generic name than PDFResult.

Generic names will be nice, and I think a good aproach will be to have 
input parameters and outputstream (as well as response headers) ready 
for a PDF application.
Maybe the GenericPDF action can have a setFileName(response) method, a 
setLength(long size) method and recive (or hold) the PDF parameter map 
inside, as well as exposing in an easy way the outputstream to write our 
PDF to people. I'll be nice to have the response reset at action start, 
and all the headers stuff (application/pdf) already setup, as well as 
some kind of configuration flag to establish the disposition header 
(attachment / inline).

>> Writing FO can be kind of tedious, while IText has an API that is 
>> pretty well suited to just flowing text in if you have simple needs. 
>> I haven't used either exhaustively -- my day job is a LOT about 
>> generating PDFs but ours need much finer design control than either 
>> of those APIs really support.
I've been fighting both fo and iText. Fo is tedious, as well as raw 
iText is. My choice goes to JasperReports + iReports.

> I hear you... I've done probably 7-10 different methods to generate 
> PDFs over the years... I was hoping to do something simple and generic 
> enough to cover the 80 in the 80-20 rule :)
>> It seems like design of a generalized (custom) XML format for 
>> describing PDF templates for iText is a pretty big chunk of 
>> responsibility which doesn't really belong at Struts.  It seems like 
>> something that should be done in cooperation with the iText team for 
>> eventual integration to their project, or if not, to be served 
>> independently.
> That's definitely a fair point.  There is actually a project outside 
> iText that provides an XML format already, although for the purposes 
> of what I'm talking about it's license isn't amenable (LGPL, which I 
> recall being not acceptable to the ASF).  I'll tell you though, I wish 
> I had seen that before I wrote my own :)

JasperReports ( is an xml schema 
for iText, in a similar (but I think far more extensive and complex than 
yours). It handles XML files, turns them into iText code and the you 
pass a DataSource interface to fill the fields in. The good news are 
jasperreports has a crystal-report-style visual editor. Jasper has been 
out ther for a long time and they haven't get iText support (well, they 
haven't merged iText). It's license is LGPL. I just tell this because 
maybe you (Frank) should think about moving to JasperReports before your 
XML schema grows too big. Feel free to mail me asking questions, I've 
been developing with Jasper (and hacking it as well) for over two years.

>> Is there any problem with iText's license? (dual LGPL/MPL)?  May be 
>> worth a look at PDFBox, which is BSD licensed:
> Yeah, I think your right about that too.  PDFBox looks interesting... 
> although I'm not sure I want to build against something that hasn't 
> had a 1.0 release yet (hehe, JWP excepted of course!! LOL)
> But good ones :)  The license issue with iText alone is a good one... 
> that starts to push me towards FOP more than likely, which might 
> ultimately be better since it'd allow for more than just PDF output. 
> Like I said, I'll have to do some playing with that to convince myself 
> it won't be a burden to work with.
Personally I think the main goal will be made things easy for us, real 
life programmers. It's a fact that some use FOP but it's a fact that 
others don't. The goal then turns out for using FOP, as it turns out for 
using iText. I think the aproach *SHOULD* be an easy way to integrate 
any kind of PDF generation in a plugable / extensive way. Once you've a 
base PDF action (how many times I've had mine!), that is, as I mentioned 
before, response headers, filename, length (if any) and disposition -to 
cache or not to cache is out of this scoope, already covered by the 
framework- as well as input parameters -covered by the framework- and a 
easy/lazy access to outputstream, things should be easily extensible, 
for example:

 - Frank can extend and just pass an adittional parameters, XMLtemplate, 
fill in the gas Xps and had hiMLTemplatedPDFResult in few lines of code, 
ready to use and bug free (as in beer?).
 - Joe, in the other side, will write a FOResult with whatever foo needs 
(template and base document) a new result ready.
 - I can write a jasperreports one, with new magic functionality ready.

What's the point? We three donate our work to the project and soon, the 
project will be filled with those 70 or-even-more ways of generating PDFs.
Ok, maybe this will turn in a Commons-PDFing (j/k like commons-logging) 
abstract PDF API but well, giving support for a standard way, extensible 
via plugins will make things easy.
Anyone can extend to support his own PDF thing, but much better, PDF 
generating frameworks will have an easy way to offer the plugin/result 
object/action/thing in it's own library. What can be better than 
download iText, put a config parameter and have a iText PDF action ready 
coding no lines? And what about doing the same with jasper or FO?



PD: Please forgive my english since It's been a long time since I last 
wrote an extense aggregation of thoughs into an email.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message