On 25.08.2005 22:17:33 Simon Pepping wrote: > Jeremias, > > It is a good package. I have a few remarks.
Thanks a lot for taking time to review! > 1. At some point I wanted it to be possible to set input and output > types on the Factory. In that way it would be possible to write a > factory implementation which knows about several of the processing > engines, and depending on the input and output types (and some user > configuration, at the discretion of the factory implementation) > could choose the best engine, e.g. JFOR for fo to rtf, FOP head for > fo to all other, Batik for SVG to other. Almost sounds like Nicola Ken Barozzi's Morphos idea [1]. :-) It didn't work out back then. But the idea was good. [1] http://svn.apache.org/viewcvs.cgi/jakarta/commons/sandbox/morphos/trunk/?rev=146738 > But that would introduce input type dependence into the > code. Hmm, I think it is possible (though probably not worth the effort) to write a special factory builder/provider that analyzes the input file and choosing the effective XGProcessorFactory much like we do that with our image analyzers in FOP. This wouldn't even have to be part of the API. This could simply be an external component. > Currently the following code: > > XGProcessorFactory factory = XGProcessorFactory.newInstance(); > XGProcessor processor = factory.newXGProcessor(); > Source src = new StreamSource(new File(args[0])); > XGResult res = new StreamXGResult("application/pdf", new File(args[1])); > processor.process(src, res); > > together with the appropriate value of the system property can be > used to process both FO and SVG, with the engine of choice by the > invoker. > > 2. I am a bit suprised that you use a specific factory implementation > in your examples, and not the engine agnostic newInstance > method. This is counter to the goal of engine agnostic code. > > This made me think that perhaps another goal is more important: > This is a framework that allows one to access each engine through > the same interface. It does so by writing adapters between the > defined interface and the engines. Exactly. There are different ways that you can obtain a factory instance. Unlike with JAXP I don't want to tell you how exactly to do this although you CAN do it the JAXP way. This comes out from the necessity for supporting multiple FO processors in the same VM (also the reason for the XGProcessorFactoryProxy and the DeploymentPackage class). With JAXP you will generally be happy with exactly one implementation for the whole VM. > Viewed this way, the reference implementation is not just that. It > is the essential part of your package, viz. the set of adapters. > > 3. The interface is not limited to XML Graphics applications. It is > suitable for any engine that exposes a SAXResult interface, or can > be made to expose such an interface by an adapter. It doesn't necessarily have to expose SAX functionality to feed in the XML but it's probably to most flexible (and for some packages like FOP the fastest) way. It's perfectly feasible to write an implementation of the API the passes the input XML to the engine as a DOM or as a stream. The only problem is the need for buffering in the case of the XGProcessorHandler. It would be no big deal to write an implementation of the API that calls an external C-written program using System.exec(). > I hope these thoughts make sense. Absolutely. Thanks for them. > Regards, Simon > > On Mon, Aug 22, 2005 at 12:23:45PM +0200, Jeremias Maerki wrote: > > I've cleaned up JAXG and published it on my website: > > > > http://www.jeremias-maerki.ch/dev/jaxg/ > > > > Comments are welcome. > > > > Jeremias Maerki > > > > -- > Simon Pepping > home page: http://www.leverkruid.nl Jeremias Maerki
