xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manuel Mall ...@arcus.com.au>
Subject Re: DO NOT REPLY [Bug 35939] New: - [PATCH] Port of 0.20.5 Driver.java class
Date Tue, 02 Aug 2005 00:30:54 GMT
On Tue, 2 Aug 2005 12:31 am, 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.

No problem for me as can easily have my private fop-compat.jar as long 
as nobody introduces an incompatible Driver.java into the trunk.
>
> 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.
>
Makes sense to me. Actually this is exactly what the 0.20.5 Fop.java 
does. It just has one main method of less than 30 lines. The question 
is where should the API reside. In 0.20.5 it resides in Driver.java but 
in the current trunk its in Fop.java coupled with the CLI which is what 
you (rightly so in my opinion) criticize. May be factoring it out, 
however not into Driver (if I recall correctly people didn't like the 
name), but into another API only class (FOProcessor.java ?) is a 
solution?

Manuel
>
> Greetz,
>
> Andreas

Mime
View raw message