On Aug 1, 2005, at 11:37, Manuel Mall wrote:
no argument from me against what you are proposing and also Joerg in
can still have a Driver.java for backwards compatibility for those who
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
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.