xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas L Delmelle <a_l.delme...@pandora.be>
Subject Re: API discussion (was: DO NOT REPLY [Bug 35939] New: - [PATCH] Port of 0.20.5 Driver.java class)
Date Wed, 03 Aug 2005 00:20:39 GMT
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  

<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  
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  
   URL srcFileloc, URL xslFileloc, URL tgtFileloc --we could determine  
the output target from tgtFileloc's extension (in a lot of situations)

   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:  
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.



View raw message