xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas L Delmelle <a_l.delme...@pandora.be>
Subject Re: DO NOT REPLY [Bug 35939] New: - [PATCH] Port of 0.20.5 Driver.java class
Date Mon, 01 Aug 2005 16:31:35 GMT
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.

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 :-/

The following may make little sense to you, but just in case there are 
others following this thread:
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.

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.


Greetz,

Andreas


Mime
View raw message