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
