Thread: [xmlenc-devel] New XMLOutputter approach
Brought to you by:
znerd
From: Pete C. <pe...@fi...> - 2003-01-09 16:40:17
|
Ernst, > The old way of constructing an XMLOutputter object: > > XMLOutputter outputter = XMLOutputter.getInstance(writer, encoding); > > The new way: > > XMLOutputter outputter = new XMLOutputter(); > outputter.init(writer, encoding); > > And when you want to use the outputter for a new Writer: > > outputter.reset(); > outputter.init(writer, encoding); > > What do you think of the new way? What, exactly, does outputter.reset() do? Will it ever be called independent of init()? If not, maybe it would be cleaner to instead do: outputter.reset(writer, encoding); You could also overload it and have outputter.reset() for cases when you don't need a different writer or encoding. I guess I'd like to see the reuse case be done with a single method call if that makes sense, just so people can't forget the reset() or the init(). I think this was a good idea though. I can envision cases when I'll need to write several XML files at once, and this way I can reuse the outputter(). (Maybe similar to a database connection or something.) Gratefully, Pete Cassetta pe...@fi... ------------------------------------------- Fingertip Software 433 Kitty Hawk Rd., Suite 216 P.O. Box 2487 Universal City, TX 78148 Orders: (800) 209-4063 -or- (210) 659-6832 Support: (210) 659-2532 Fax: (210) 659-8870 http://www.fingertipsoft.com ------------------------------------------- |
From: Ernst de H. <znerd@FreeBSD.org> - 2003-01-10 21:14:55
|
Hey Pete, > What, exactly, does outputter.reset() do? Will it ever be called > independent of init()? If not, maybe it would be cleaner to instead do: The idea was that a worker thread could call reset() when it's done and then init() when it starts working again. For example when XMLOutputter instances are kept in a pool. > outputter.reset(writer, encoding); > > You could also overload it and have outputter.reset() for cases when you > don't need a different writer or encoding. I guess I'd like to see the > reuse case be done with a single method call if that makes sense, just > so people can't forget the reset() or the init(). I see your point. On the other hand I've got another requirement, and that is that it must be possible to create an XMLOutputter instance that has no Writer associated with it yet. So perhaps we should combine this with your suggestion and have: XMLOutputter() { ... } // State: UNINITIALIZED XMLOutputter(Writer, String) { ... } // State: BEFORE_XML_DECLARATION reset() { ... } // State: UNINITIALIZED reset(Writer, String) { ... } // State: BEFORE_XML_DECLARATION > I think this was a good idea though. I can envision cases when I'll need > to write several XML files at once, and this way I can reuse the > outputter(). (Maybe similar to a database connection or something.) Exactly. I really look forward to retesting the xmlenc performance with this new approach in place! Regards, Ernst -- Ernst de Haan Development Team Leader Wanadoo Nederland B.V. The Lord has truly risen! Merry Christmas and a blessed New Year! |
From: Ernst de H. <znerd@FreeBSD.org> - 2003-01-10 21:14:48
|
This has been implemented. It will be released in 0.23. Ernst On Friday 10 January 2003 08:40, Ernst de Haan wrote: > Hey Pete, > > > What, exactly, does outputter.reset() do? Will it ever be called > > independent of init()? If not, maybe it would be cleaner to instead do: > > The idea was that a worker thread could call reset() when it's done and > then init() when it starts working again. For example when XMLOutputter > instances are kept in a pool. > > > outputter.reset(writer, encoding); > > > > You could also overload it and have outputter.reset() for cases when > > you don't need a different writer or encoding. I guess I'd like to see > > the reuse case be done with a single method call if that makes sense, > > just so people can't forget the reset() or the init(). > > I see your point. On the other hand I've got another requirement, and > that is that it must be possible to create an XMLOutputter instance that > has no Writer associated with it yet. So perhaps we should combine this > with your suggestion and have: > > XMLOutputter() { ... } // State: UNINITIALIZED > XMLOutputter(Writer, String) { ... } // State: BEFORE_XML_DECLARATION > > reset() { ... } // State: UNINITIALIZED > reset(Writer, String) { ... } // State: BEFORE_XML_DECLARATION > > > I think this was a good idea though. I can envision cases when I'll > > need to write several XML files at once, and this way I can reuse the > > outputter(). (Maybe similar to a database connection or something.) > > Exactly. I really look forward to retesting the xmlenc performance with > this new approach in place! > > Regards, > > > Ernst -- Ernst de Haan Development Team Leader Wanadoo Nederland B.V. The Lord has truly risen! Merry Christmas and a blessed New Year! |