I'm not in a fighter mood today so please change getContentHandler() to something other than public, make sure you check the test cases regularly, adjust the example code to the new API and keep in mind that Cocooners will want to migrate their FOPSerializer some day (They use getContentHandler() at the moment).
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/fop/java/org/apache/cocoon/serialization/FOPSerializer.java?rev=1.5&content-type=text/vnd.viewcvs-markup On 08.11.2003 21:48:52 Glen Mazza wrote: > --- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > > As you may have seen in the CVS messages I have > > moved most of the setup > > code that was in the render() method to the > > getContentHandler() method. > > This is necessary because not everyone uses the > > render() methods, > > Well, what is wrong with everyone using the render() > method for 1.0? It is precisely between major > releases, as opposed to within minor patches--that > APIs may change. That's the direction we've been > going for 1.0--and we've had zero complaints on the > user list about it. > > > sometimes you simply need to have a ContentHandler > > to send SAX events to. > > But evidently not, given the code functionality > unrelated to getting the content handler that you > needed to move out of the render() functions, and into > getContentHandler() to get this to work. > > Why are you providing multiple access paths to doing > the same thing in FOP? What is wrong with calling the > render() function--how does calling > getContentHandler() help performance over just having > a render() functions? > > > Some of our examples (and some of our basic test > > cases) use that > > approach. > > > > They can be rewritten. What I need to hear is how > performance suffers (or the coding becomes > inordinately burdensome) as a result of just having > the render() functions exposed. Juggling multiple > API's doesn't help anyone. Jeremias Maerki
