This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Well I'm working on part of an application where I need to manipulate XML. My basic problem is that I need to read an XML document, present the information to the user, allow the user to modify it, and then write that to a new file. The XML represents bill information, the thing is I need to work with only one bill at a time, and each XML file could have an indefinate number of these bills, from 1 to 20,000+. So start with bill 1, get the data, let the user modify it if need be then save it to a new file and move on to the next bill, writing that one to the end of the same file. My approach was to define my own "element" class that stores information on an element, name, namespace, value, attributes, parent element, child elements, etc. and pass these from the SAX handler to another class which keeps them in a collection. Then I work with that class to get and change the information I need. This seems to work pretty well and the only real problem I've had is dealing with the output, I have to create a new file and write an indefinate number of bills to it one bill at a time. I managed to do it using a FileWriter but the code is pretty shitty and its only a temporary solution. My question is... how can I do this better? I'm just looking for any suggestions from scratching my entire approach and doing something different to just finding a good way to handle the output. Any help is appreciated.
Actually I kinda liked your first approach parsing one bill at a time out of SAX. But why make an "element" style class? Make a real business object that could be used with or without XML, and then something else that can turn it back into XML when done. Here's a write up I did on Reusable Sax Parsers that work this way. On the other hand, I've never touched JDOM. It might do a spectacular job ... sounds like there may be lazy instantiation to keep from building the whole DOM in memory at once. How does this approach fit with your users? Do they have to work the entire file at one sitting? Is it a requirement to be able to stop half way through and pick up again later? [ July 20, 2003: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi