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 (http://jasperreports.sourceforge.net) 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: http://pdfbox.org/
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?
Cheers,
Juan
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
