xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <dev.jerem...@greenmail.ch>
Subject Re: API discussion (was: DO NOT REPLY [Bug 35939] New: - [PATCH] Port of 0.20.5 Driver.java class)
Date Tue, 02 Aug 2005 09:14:41 GMT

On 01.08.2005 18:31:35 Andreas L Delmelle wrote:
> On Aug 1, 2005, at 11:37, Manuel Mall wrote:
> > no argument from me against what you are proposing and also Joerg in 
> > [1]. We
> > can still have a Driver.java for backwards compatibility for those who 
> > want
> > to "plug and play" either in the product, or in a separate jar
> > (fop-compat.jar?), or just here in BugZilla.
> Well, I've thought about that as well --keeping the Driver FTM as a 
> sort of 'deprecated proxy' that simply forwards the method-calls to the 
> respective components in the new API, but...
> IMO this is not an absolute necessity. If we decide on discontinuing 
> support for the 0.20.5 API, then we may as well do it now.

Right. People just don't like API changes and the path away from the
Driver class a big break.

> The main point is however, that with the current design, implementing 
> such a proxy looks rather clumsy --this has absolutely nothing to do 
> with your coding, but is a consequence of the merging of component and 
> standalone app... Right now, the Driver would have to be wrapped around 
> the main-class, which is something I do NOT like :-/

I doesn't have to. The Fop class is so light-weight (if you think the
main() method plus helpers away). You can easily reproduce that code if
a few lines in that proxy.

> The following may make little sense to you, but just in case there are 
> others following this thread:

I VERY MUCH hope that there are!

> I feel that the class that will be used for running FOP from the 
> command line should be an example in itself, in that it should use the 
> component in the same way an embedding user would. Only difference is 
> that the configuration will be created based on the command line 
> parameters.

I'm not fully happy either, especially, after I put in the classloader
stuff. My proposal would be to do the same I did in Barcode4J: Let's
create a "cli" package with the whole command-line stuff in there. See:

> Our CommandLineOptions class should build a Configuration which the 
> main-class can then pass into the configure() method of the component. 
> It really does not need to --or stronger: it shouldn't-- concern itself 
> with initializing the OutputStream, for example.
> Roughly its tasks should be limited to:
> - tell the CommandLineOptions to construct a Configuration based on the 
> parameters specified on the command line
> - tell the component to configure itself with that Configuration object
> - tell the component to go about its business (start() or run())
> That class should, if I estimate correctly, be about 50 lines of code. 
> Right now, we have a main() method in the Fop class at line 300+, which 
> seems fishy to say the least.

Yes, it's become too big to be of educational value.

As a side note: Keep in mind that I've written a general API which
easily handles calling FOP 0.20.5, FOP Trunk, JFOR, FOray and even Batik
for the conversion of XSL-FO or SVG to PDF, PS, Print etc. It is
designed to provide for the various XSL-FO implementations what JAXP is
for Xerces, Crimson, Xalan, SAXON etc. The only problem is that I still
don't have a name for it that doesn't produce any problems (JAFOP was too
close to FOP to potentially scare commercial implementors away and JAXG,
its current name, has been criticized by a Sun employee to be
potentially problematic because of the use of the "JAX" prefix.)

Jeremias Maerki

View raw message