On 07.07.2004 05:41:11 Glen Mazza wrote: > --- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > > > > Using > > a DOMSource and a SAXResult with an identity > > transformer. > > > > Do we already have an example for this one? I'm not > sure of what you mean--are you saying that Manuel can > continue doing exactly what he's doing (slurping a FO > file into a DOM Tree, manipulating the tree by adding > RDBMS values to it, then sending the DOM Tree off to > FOP to be published) with what you mention above?
Advertising
Yes, exactly. Take the XML2PDF example. I'm copying the important part and only have to change two lines to (1) use the identity transformer instead of an XSLT stylesheet and (2) using a DOM as source instead of an XML file. driver.setOutputStream(out); // Setup XSLT TransformerFactory factory = TransformerFactory.newInstance(); //Transformer transformer = factory.newTransformer(new StreamSource(xsltfile)); Transformer transformer = factory.newTransformer(); //identity transformer // Setup input for XSLT transformation //Source src = new StreamSource(xmlfile); Source src = new DOMSource(mydomnode); // Resulting SAX events (the generated FO) must be piped through to FOP Result res = new SAXResult(driver.getContentHandler()); // Start XSLT transformation and FOP processing transformer.transform(src, res); > Also, under the hood, do you suspect that the identity > transformer is the same thing as our two classes? I'm > far from an expert at this. Not the same, but has the same effect. > > On the > > other side, the two > > classes are perfectly usable and useful stand-alone > > outside of FOP. > > > > I would guess those two classes are a dime a dozen, > probably in 100 articles and books. But a non-FOP > user can always take the source code and incorporate > them in his/her program. That's right. > But FOP is not XML Commons, and IMO external users > should not be directly latching on to non-XSL portions > (i.e., not fonts or hyphenation, etc., things that we > are expected to share) of our code that way. That > would limit our ability to modify/optimize/simplify > the code to provide a solid XSL implementation. I'm not sure I understand this paragraph correctly. Does that mean that you will be against factoring out certain basic components from FOP into a separate area so they can be more easily reused by others and improved by people not really seeing through FOP's code forrest? > > In the end I don't see what is gained by moving > > these two classes around > > and by reducing their visibility. > > My thinking: > > We can get rid of them in the future, without worrying > about backwards compatibility. Ok. > We can move, rename, merge, modify them without > worrying about external use. Yes, but what's the benefit about moving them around when they were in a place where nobody was bothered by them and they were doing their job? > Fewer moving parts and fewer access paths means fewer > bugs and less confusion both on the FOP-USER list as > well as with developers. Well, these two classes are certainly not cause to any pain. If I've seen that correctly the code has never been semantically changed sence its separation from the Driver code in 2001. Kelly Campbell wrote then: "Refactored Driver to simplify usage required for other apps to integrate Fop." > Also, we're placing them precisely in the package, and > the only package, in which they're being called. This > makes the packages less dependent on each other. > > But the visibility is actually less important to me > than the location. If it would make you more > comfortable, I'm willing to make them public, but I > would prefer them to stay in apps. (We can also wait > first until we get hate mail--exposing them is very > simple--but if we never get such mail we know they are > no longer needed.) There is a good chance that nobody uses this code at all, yes. But in all no strong points IMHO to motivate this change. NTARS. > > It's simply a fact > > that many people > > still work with a DOM and I know a few programmers > > who are very hard to > > talk into adopting a different style of dealing with > > XML. > > They won't need to--we will happily continue to be > supporting DOM Trees within FOP. Moving them to apps > also shows their first-class ranking alongside > XSLTInputHandler and FOInputHandler. Ok, I will shut up about this now. Jeremias Maerki
