the new XML reader/writer
the new XML reader/writer
umm, so what does forward only mean? does this xml reader read in the entire file into structures first or does it read tags one nugget at a time - i tend to rely on having the whole structure in memory and being able to look ahead - i have the sneaking bad feeling that forward only means that you have to take tags as they are read ... - if thats the case then sadly i need to stick with tinyXML for my file formats - but good to see xml finally embedded in a graphics engine - i tried to promote that idea a long while ago in ogre and got shot down - some crazy beliefs that xml was too verbose for game files - silly really, its just text that compresses very well
There are 2 ways of processing, not reading, an XML file:
The first one is great when you have several files to process, especially when you only want to process them once, which would be the case of config files.
The latter is good in cases where you want to load a bigger file and use it for a longer time and possibly for numerous accesses. Also you don't have to construct a data container yourself, you just use the DOM tree that is given to you. But loading the tree is many times slower then the event processing, so not liable for real time stuff and of course you'll hold the whole tree (XML file with overhead) in memory all the time.
So each format has it's pros and cons. But apart from the new xml-configs I don't know what the new XML loader is good for
Greetz, pat le xml'ed
- Event Processing
- DOM Processing
The first one is great when you have several files to process, especially when you only want to process them once, which would be the case of config files.
The latter is good in cases where you want to load a bigger file and use it for a longer time and possibly for numerous accesses. Also you don't have to construct a data container yourself, you just use the DOM tree that is given to you. But loading the tree is many times slower then the event processing, so not liable for real time stuff and of course you'll hold the whole tree (XML file with overhead) in memory all the time.
So each format has it's pros and cons. But apart from the new xml-configs I don't know what the new XML loader is good for
Greetz, pat le xml'ed
The internal one is good for simple xml files.
But the limitation that I hit like a brick wall was the parentage.
I have my guihandler class 90% converted, but the problem I hit on is that my xml has child gui elements to the parent gui elements defined by their parentage in the XML.
I can't figure out how to grab the parentage using it.
The only option I have would be to have an attribute assigned in the xml that points out who it's parent is. But that way around is way more work.
But the limitation that I hit like a brick wall was the parentage.
I have my guihandler class 90% converted, but the problem I hit on is that my xml has child gui elements to the parent gui elements defined by their parentage in the XML.
I can't figure out how to grab the parentage using it.
The only option I have would be to have an attribute assigned in the xml that points out who it's parent is. But that way around is way more work.
Crud, how do I do this again?
A solution for this would be to make a recursive function for reading the xml file. Something like that:
Code: Select all
void parseFile(IXMLReader* xml, IYourClass* parent)
{
xml->read()
IYourClass* data = createYourClassFromXMLData(parent);
if (xml->getNodeType() == o::EXN_ELEMENT)
parseFile(xml, data);
}
Alright, lets use this example to make sure I got my head on straight:
The element <gui> is a EXN_ELEMENT. If I did isEmptyElement(), I would get false. When at last, the code gets to </gui>, it would be an EXN_ELEMENT_END. Since the name of the element is gui, I would know that I am at the end of the contents of that xml element.
Alternately,
<element type="IGUIButton" id="101" top="210" left="10" height="30" width="90" text="Quit" /> would be an EXN_ELEMENT, but isEmptyElement() would return true since there are no children.
Right?
Code: Select all
<gui>
<layouts>
<layout id="1" name="userinterface" visible="true">
<element type="IGUIButton" id="101" top="210" left="10" height="30" width="90" text="Quit" /> </layout>
</gui>
Alternately,
<element type="IGUIButton" id="101" top="210" left="10" height="30" width="90" text="Quit" /> would be an EXN_ELEMENT, but isEmptyElement() would return true since there are no children.
Right?
Crud, how do I do this again?
i wanted to use the XML for a scene description file (my 3DML) but it would be quite a bit more complicated using a forward only parser - being able to look ahead in the xml tree is VERY helpful - but i will see if i can simplify a few things and still use the xml parser - it would be nice to remove one more library from my dependency tree
We'll find out in a few hours when I get home to compile my code.
I made a slight modification to it. Since I'm recursing, I have my code sending each child recursing until it hits an EXN_ELEMENT_END. I check to make sure that it is its terminator.
<gui>
---->Send child <element> to function
---->Send child <element> to function
---->Send child <element> to function
</gui>
//!Found the terminator, exit function to back up to let my parent finish.
I made a slight modification to it. Since I'm recursing, I have my code sending each child recursing until it hits an EXN_ELEMENT_END. I check to make sure that it is its terminator.
<gui>
---->Send child <element> to function
---->Send child <element> to function
---->Send child <element> to function
</gui>
//!Found the terminator, exit function to back up to let my parent finish.
Crud, how do I do this again?