This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I have an xml doc and I am supposed to parse it via dom parser which I think I did (I started reading about it yesterday so not so sure what it is).
The thing is I have the nodes list.
Now I want to make an object out of it. I do know the attributes and all and they are not going to change (only the number of nodes may increase, it will not decrease though)
I want to add the decoding method in the object's class, so if I have a generic element value I could use for example:
But they way I wrote it , it does not extract it from a generic object with element fields but it is a node list, so the decoding method is using method (which I understood to be a dom method...correct me if I am wrong).
So either I keep the nodelist in main program which holds all the various object lists and then it can send the node to the object class for decoding so all the xmlreader class does is get me the nodes and the object classes do the decoding for the fields.
Or as it is now, the xml holds all the methods for parsing and decoding which means that if I add a new type of object to the xml (which I won't but just for the idea) I will have to edit the xml file.
What would be the best way to read xml file using dom parser in the neatest way so it is as generic as possible and easy to read and make changes later on?
It doesn't have to be one of the ways I suggested.
Plus is it correct (design wise) to have all the decoding in the xmlreader class? it seems wrong to me...
and let me know if I didn't use xml parser dom because I am not familiar with it so I am not sure (the part confusing me is it uses a sax exception)...I think it of a group of methods dealing with nodes.
ps: naturally each object in the xml file has different number and types of fields (properties).
This is my xmlreader class:
The last method which builds the object is the method I want to generalize.
Personally I make object constructors that take an org.w3c.dom.Element - that puts all your decoding in one place.
It is also convenient to make a toXMLString() method in your custom class.
Some folks like to use the java.beans package.
Joined: Jan 29, 2014
Not sure what you mean by toXmlString()
Did you mean editing the xml file? (adding lines).
If I keep the element in the object class it does solve teh decoding.
But then who keeps the nodes array?
I could keep a nodeArray in my main program then call the object class to decode it.
Seems like best solution so far ...Only that it means I need to keep nodeArray in my main prog rather than keeping it hidden.
I prefer saying with the object level for the main class but I don;t see a way to do that since I am not sure I want the xml costume class to communicate with any of my object classes and creating
Author and all-around good cowpoke
Joined: Mar 22, 2000
I use a toXMLString() method to create a String representation of the data in the object in the text format of an Element - in other words with an opening Element tag, various content tags and a closing Element tag.
That way if I want to write an XML document representing the state of a collection of these objects I just have to write a document root, iterate through the collection writing the results of toXMLString(), and a closing document root.
You could also write a toXMLStream( OutputStream out ) where you prepare an OutputStream to write to a File for example, and call that method for each object.
This is sort of what the java.beans package provides but I prefer to write my own.
The question of where to keep the NodeList is up to you.