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

  • Re: API discussion (was: DO NOT REPLY [Bug 35939] New:... Andreas L Delmelle

Reply via email to