Thanks for the information. Working with a DOM tree
saves one the step of needing to place input data into
XML first. So retaining this functionality in 1.0
will keep the flexibility to users in how they can
approach a report-generation task. I guess we should
keep it in then.
Thanks,
Glen
--- Manuel Mall [EMAIL PROTECTED] wrote:
Glen,
A 1. We do preload an FO file into a DOM tree,
navigate it, do manipulations, and then send it
off to be published into PDF.
A 2. At the time it seemed the easier way of doing
it.
Would we still be doing it again instead of using
XSLT?
Hmm, our input data is not in XML but comes from a
RDBMS and other sources. So we would have to convert
this into custom XML and restructure our current FO
files to become XSLT stylesheets. Its doable and
would
certainly be more standards compliant. Would it be
simpler / easier? As it stands now for any
formatting
changes we just edit the FO file. In future it would
mean
editing the XSL file = No loss or gain. For data
structure
changes we need to modify the FO file and the code
setting up the final DOM tree. In future we would
need
to change the XSL and the code creating the XML
from the data = Again no loss or gain.
Manuel
- Original Message -
From: Glen Mazza [EMAIL PROTECTED]
Thanks--you're the first I've heard using it.
May I ask:
1) Do you manually create the FO document from
scratch
similar to the first example I gave in my previous
email? Or, do you preload an FO file into a DOM
tree,
navigate it, do minor manipulations, and then send
it
off to be published into PDF?
2) Is using DOM Trees an optimal way for you to do
your work, or is it just legacy code you don't
wish to
disturb? (I.e., if you had to rewrite it from the
beginning, would you still use DOM Trees?)
Glen
--- Manuel Mall [EMAIL PROTECTED] wrote:
From: Glen Mazza [EMAIL PROTECTED]
Team,
But does anyone generate FO documents via DOM
Trees
anymore?
Yes, we do in a back office fop intensive
server
application.
Manuel
