Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Mime-Version: 1.0
Message-Id: <a06230928c0aa41a9e236@[192.168.2.110]>
In-Reply-To: 
 <58968.170.201.180.137.1149536321.squirrel@webmail.chiron.lunarpages.com>
References: 
 <55386.170.201.180.137.1149534775.squirrel@webmail.chiron.lunarpages.com>
    <44848500.5040909@fdar.com>
 <58968.170.201.180.137.1149536321.squirrel@webmail.chiron.lunarpages.com>
Date: Mon, 5 Jun 2006 15:28:31 -0500
To: "Frank W. Zammetti" <fzlists@omnytex.com>,
        "Struts Developers List" <dev@struts.apache.org>
From: Joe Germuska <Joe@Germuska.com>
Subject: Re: [SAF2] Tossing an idea around: PDFResult
Cc: "Struts Developers List" <dev@struts.apache.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 3:38 PM -0400 6/5/06, Frank W. Zammetti wrote:
>Not a bad idea... I've never been a big fan of XSLT, always seemed overly
>difficult to me for what it was, but certainly sticking with a standard
>has appeal, and I've done a little bit of FOP work, so it's not all new.
>
>One thing I was thinking about for the Ajax result stuff was to have
>optionally a toXML() and toJSON() method on the Action... if they are
>present, they would be used by the Results rather than the automatic
>generation process... would allow for more complex outputs than the
>automatic process is capable of.. having toXML() on the Action might be a
>good idea in general, precisely for things like PDF generation and the
>XSLT Result you mention.  Maybe some default implementation (the one from
>AjaxXMLResult possibly?) in ActionSupport might open some doors?
>
>In any case, I may have to play with your suggestion a bit and see what it
>might look like... I like the idea of using standards, but I have some
>doubts as to how easy it would be for developers to use, generally.

It depends a lot upon your use case -- but for starters, this very 
question suggests that if you do write anything, you should call it 
ITextResult, or FOPResult, not PDFResult.

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.

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.

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/

Just a few fragmentary thoughts...

Joe


-- 
Joe Germuska
Joe@Germuska.com * http://blog.germuska.com    

"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed.  Try something new."
	-- Robert Moog

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org