Mailing-List: contact fop-dev-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: fop-dev@xmlgraphics.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Tue, 02 Aug 2005 11:14:41 +0200
From: Jeremias Maerki <dev.jeremias@greenmail.ch>
To: fop-dev@xmlgraphics.apache.org
Subject: Re: API discussion (was: DO NOT REPLY [Bug 35939]  New:  - [PATCH]
 Port of 0.20.5 Driver.java class)
In-Reply-To: <2949dcb0c4a7284932969a0e4336d4c8@pandora.be>
References: <200508011737.37787.mm@arcus.com.au>
 <2949dcb0c4a7284932969a0e4336d4c8@pandora.be>
Message-Id: <20050802105735.23BA.DEV.JEREMIAS@greenmail.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit


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:
http://cvs.sourceforge.net/viewcvs.py/barcode4j/barcode4j/src/java/org/krysalis/barcode4j/cli/

> 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