On Aug 2, 2005, at 11:14, Jeremias Maerki wrote:
On 01.08.2005 18:31:35 Andreas L Delmelle wrote:
... 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.
Yeah, seems I was jumping the gun a bit... After all, it's 300+ lines,
only if you count all comments and whitespace :-)
<snip />
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/
Funny, right before I read your reply and without having looked at
Barcode4J, that was EXACTLY what I was thinking about. That way, it
becomes possible to build a JAR without the CLI classes, for people
that hardly ever use FOP from a console. Those that need only
occasional runs via CLI need simply an additional jar on their
classpath that contains only FOP's CLI classes. It's not that there are
many, but still, for the purists this means that they don't need to
contaminate their environment with those classes (that are not
re-usable in other contexts: see Joerg's remark earlier on).
Plus: separating the CLI means that we're more at liberty to add
dependencies there without forcing our API-users to drag them in as
well. (Ideas? Still a wild one ATM, but Jakarta Commons' Launcher
seemed interesting: IIC, it can be used to handle the tasks we now deal
with in our startup scripts --which would mean that we have to maintain
that stuff only in one place--, offers fine-grained control over the
class-loading.)
<snip />
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.
Yes, I remember. Of course, that is one side: a matter of conforming to
a set of interfaces.
How we implement them and map the general API to our own is another.
One thing's for sure: such mapping will be much easier if our specific
API is neatly designed, regardless of what the general interfaces look
like.
I'm very much in favor of the idea, and my preference in that area is
towards a *very* abstract and stringent general API, even if that would
mean that for all of the above apps someone still needs to code
API-to-API (specific-to-general) bridges. Evidently, there can be
absolutely no references whatsoever to any of those particular
applications in the general API --ideally it should be designed by
someone who knows nothing about those particular apps' usage patterns,
but who understands what a FO or SVG processor is/does (besides being
very proficient in Java interface-design, of course :-))
It is designed to provide for the various XSL-FO implementations what
JAXP is
for Xerces, Crimson, Xalan, SAXON etc.
After all, I'm currently wondering if Xalan or SAXON ever started out
as an attempt to write an implementation for JAXP, or if their initial
concern was to code a decent XSLT processor and they added the JAXP
conformance further on. (I'd guess it lies more in the direction of the
latter, but I'm not sure at all)
And, now that JAXP is mentioned: of course, it's beneficial to expose
that API's functionality in our own --after all, it's *XSL*-FO--,
however, we should probably allow a number of possibilities, ranging
from:
URL srcFileloc, URL xslFileloc, URL tgtFileloc --we could determine
the output target from tgtFileloc's extension (in a lot of situations)
over
File srcFile, File xslFile, File tgtFile
over users passing in their own InputSources, Transformers and
OutputStreams, or in the end maybe even
Source src, Style style, Target tgt --where those three are our own
independent interfaces, and user-developers can code their own
customized implementations. As long as their objects know how to
produce sensible answers to FOP's questions, it will render them as
specified. This abstraction is more or less based on our Obj2PDF
example, but precisely that example would become much much simpler.
[Think of a Processor, without XML, XSLT or FO:
Object-over-Object-to-Object]
I have a feeling that such an approach would greatly simplify the
eventual idea of a pluggable Renderer framework --Target as a class
that is able to return a component that conforms to our most basic
Renderer interface. Setting it through a RENDER_TYPE constant will be
for convenience only.
Especially the simpler ones are important --for rookie Java
developers--, since *ours* is the XML API, but the users-embedders'
shouldn't necessarily be. If they're interested and clever enough, they
will be driven towards learning more about SAX and JAXP anyway. In
which case they can refine their own particular usage pattern if they
want/need to --and, who knows, ultimately maybe even help us out in
adding enhancements (or at least discuss them here, and maybe inspire
others :-)).
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.)
Wouldn't worry about the name too much right now. I believe that the
idea in itself is worthwhile enough. Some cool name is bound to turn up
for it eventually.
Cheers,
Andreas
