calling the SAX handler directly
- Apologies if my question is naive. Can I call the methods of FOP's SAX
handler directly ?
startElement( pass the name of a FOP object here)
characters( ...blah blah... )
I've read the recommended approach is to create an XML first, even if
only in memory. And then feed the XML into the SAX parser of FO.
In my case, this seems superfluous. I have two dozen items of data
which I need to place on a page, in a rather unusual pattern. So, the
main effort is in FO.
In my project, the data does not have a complex hierarchy. But the FO
is likely to be a complex hierarchy. I have to divide the page into
three zones (top, center, bottom). The center zone to be divided into
two halves along a vertical like. The left-center subzone to contain
two rectangles with highlighted borders, and the right-center another
rectagle. Data is to flow within these rectangles. Sounds like madness
(and looks like it too-:) but this is the task at hand.
I feel more comfortable expressing such FO hierarchy from Java. It just
feels pointless for me to build a tree, serialize it into XML, and then
call FO to build its own tree again. I've read the warning about FO
being able to use smaller trees than the whole document, but my case
involves a single page anyway, so there is not much to save.
Would such an approach be workable ?
- Schonberger Andras wrote:
> Apologies if my question is naive. Can I call the methods of FOP's SAXYou can call the handler directly. In fact in many cases it is
> handler directly ?
better than building an XML string and feed it through a parser.
It is, however, more common to build a DOM using a simple XML
vocabulary (rather than XSLFO) and pass it to an XSL transformation
which generates the XSLFO. Feeding a XSL Transforamtion with
SAX events also happens, there are quite a few applications where
some events map smoothly to SAX events, like parsing data files or
feeding database tables into a processing stream. Generating SAX
events for XSLFO directly is more outlandish.
Generating SAX events can be tricky, because you have to guarantee
the proper sequence of events, including startDocument etc. It is
easy to generate some out of sequence events, which will in general
lead to strange effects downstream. Be prepared for some long debug
sessions. The easiest way to debug a SAX event generator is probably
to serialize the event stream as XML document.