XSLTInputHandler constructor for InputSources?

[Rob Heittman <ro...@cluestream.com>]

Would it cause problems to provide an alternate constructor for
XSLTInputHandler ... ?

  XSLTInputHandler(InputSource xmlsource, InputSource xsltsource)

in addition to:

  XSLTInputHandler(File xmlfile, File xsltfile)

I am working with XML which is streamed directly out of a repository, not
a file, and could get rid of a bunch of lines of redundant code in my app
if I could use FOP's XSLTInputHandler instead.

If this makes sense, let me know and I'll be happy to provide a patch.

- Rob


-- 

Rob Heittman

cluestream ventures  |  effective information management
                        research, development, analysis and consulting
			http://www.cluestream.com


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

Re: XSLTInputHandler constructor for InputSources?

[Matt Savino <ma...@synergizethis.com>]

I am in the exact same situation as far as my xml source. I've currently
been using a DOM XSLT transform and sending that result to FOP. 

I built the latest CVS so I could try SAX (since the SAX input is broken
in .20.1). But as you'll see below, the times seem about the same. I
also don't know what to do about the logger errors in the latest cvs.
And finally I really like the way .20.1 shows you where the page breaks
are as it reports it's progress back to the program. Is that gone for
good? I think keeping the page numbers in rows rather than streaming
down the screen makes the console output easier to read for developers.

By the way I did a little rough benchmarking on FOP embedded in a
servlet. (I'm running on a Weblogic development box - Wintel - P-III -
933). I tried three different methods: a DOM source, a SAX stream from
an XSLT transfrom, and the XSLTInputHandler (I serialzed the xml source
out to a file). The XSLT transform is pretty simple as the xml-data is
already well structured.

Interestingly all three took between 50-51 seconds to render a ~5000
line report into a 300k, 200 page PDF document (there were a lot of page
breaks). I'm thinking that's not too bad. Especially since in our case I
don't think the end user will be able to tell the difference between
render time and download time. 

Do these numbers sound about right?

-Matt




Rob Heittman wrote:
> 
> Would it cause problems to provide an alternate constructor for
> XSLTInputHandler ... ?
> 
>   XSLTInputHandler(InputSource xmlsource, InputSource xsltsource)
> 
> in addition to:
> 
>   XSLTInputHandler(File xmlfile, File xsltfile)
> 
> I am working with XML which is streamed directly out of a repository, not
> a file, and could get rid of a bunch of lines of redundant code in my app
> if I could use FOP's XSLTInputHandler instead.
> 
> If this makes sense, let me know and I'll be happy to provide a patch.
> 
> - Rob
> 
> --
> 
> Rob Heittman
> 
> cluestream ventures  |  effective information management
>                         research, development, analysis and consulting
>                         http://www.cluestream.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org

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