Merging XML files into a single TiXmlDocument
Brought to you by:
leethomason
Menu
▾
▴
Hello!
CONTEXT: This is my first post here at the TinyXML forums, and I must admit that this tiny great library almost perfectly fits my needs... almost. At the moment, I'm retouching an OpenGL GUI (mostly for use in my little games) that uses TinyXML to parse a XML configuration file, and a incredible idea popped into my head: to tweak the TinyXML parser so that, from a single XML file, multiple "sub-files" could be defined and a merged TiXmlDocument could be built. Let me exemplify:
EXAMPLE:
// File: button.xml
// Note the "description" attributes
<button>
<element id="3" enabled="true" />
<graphical rect="250, 375, 50, 150" visible="true">
<texture filepath="GUI/textures/button.tga" />
<text description="GUI/configs/text.xml" caption="BUTTON 01" />
</graphical>
<focusable description="GUI/configs/focusable.xml" fadein="2000" />
</button>
// File: text.xml
<text font="GUI/fonts/arial.ttf" size="12" color="0, 0, 0, 1" />
// File: focusable.xml
<focusable fadein="1000" fadeout="1000">
<mousefocus filepath="GUI/textures/mousefocus.tga" />
<keyfocus filepath="GUI/textures/keyfocus.tga" />
<pressed filepath="GUI/textures/border.tga" color="1,1,1,0.5" />
</focusable>
The resulting, merged XML file (illustrative) would be:
// button.xml
<button>
<element id="3" enabled="true" />
<graphical rect="250, 375, 50, 150" visible="true">
<texture filepath="GUI/textures/button.tga" />
<text font="GUI/fonts/arial.ttf" size="12" color="0, 0, 0, 1" caption="BUTTON 01" />
</graphical>
<focusable fadein="2000" fadeout="1000">
<mousefocus filepath="GUI/textures/mousefocus.tga" />
<keyfocus filepath="GUI/textures/keyfocus.tga" />
<pressed filepath="GUI/textures/border.tga" color="1,1,1,0.5" />
</focusable>
</button>
As you have seen, some rules may apply:
- The resulting TiXmlDocument must be seen by the user as created by a single, ordinary XML file;
- All the three XML files must remain unchanged;
- Attributes must have a pointer to its original document (for descriptive error messages);
- Elements defined in "description" files have less priority than those defined "inline";
PROBLEM: I know this has almost nothing to do with TinyXML, but there isn't a better place to ask for help than this forum. I could implement this feature in the "application side", but this way I would need to replicate MUCH code all over my projects.
QUESTION: Does someone had the same problem and figured out how to solve it? If yes, could you point me the right directions? If not, would it be a good idea to change TinyXML's sources code and add this feature?
Thanks a lot!
PS.: Sorry for my bad English :( Hope you understand me...
Seems like a pretty good idea :)
But I don't think there is a way to introduce it into the library itself for all users. I could be wrong. But, for example, what attribute/element set would be the one that is chosen that *always* does the #include effect? Or would it be configurable? It gets messy quickly.
The solution IMO is between the two you proposed:
- load first doc
- write a little traverse/load function (or perhaps class) that walks the first first doc and looks for any "#include" elements
- when it finds one, it loads that document into a new tree and copies the contents into the first tree (making sure not to overwrite existing elements).
[Sidebar: it would be even better just to 'move' the element out of the 2nd tree, but at the moment I don't *think* a move function exists. Secondly that would have problems with overwriting values from the first tree.]
This logic would be in files of your own, outside of TinyXml, but shared by all your applications. You don't need to replicate code all over your projects, just share the new stuff like you share TinyXml.
WDYT?
"Seems like a pretty good idea :) But I don't think there is a way to introduce it into the library itself for all users."
=> I'm sure many guys out there would benefit from this feature, but I agree with you, just doesn't make sense to introduce it into the library for all users.
=====
"I could be wrong. But, for example, what attribute/element set would be the one that is chosen that *always* does the #include effect? Or would it be configurable? It gets messy quickly. "
=> I'd thought of passing a string identifying the attribute to be replaced (maybe in an overloaded "LoadFile" method).
=====
"The solution IMO is between the two you proposed:
- load first doc
- write a little traverse/load function (or perhaps class) that walks the first first doc and looks for any "#include" elements "
=> I must admit that your solution is more elegant than mine, because there is no need to change any existing method (just create a new one).
=====
"- when it finds one, it loads that document into a new tree and copies the contents into the first tree (making sure not to overwrite existing elements).
[Sidebar: it would be even better just to 'move' the element out of the 2nd tree, but at the moment I don't *think* a move function exists. Secondly that would have problems with overwriting values from the first tree.]"
=> Seems I'll need to spend some time figuring how to do it properly. However, your second proposed solution would leave the second tree empty, what must not occur (all the XML files must remain unchanged).
Well, time to re-read the sources and start coding :) I expect to release the resulting code in less than one week...
Thanks a lot, Ellers!
Glad it was helpful for you.
Post back to the forum when you've got it going.
One small point: the second solution (removing nodes from the #include'd tree and putting them into the original tree), thought I think not possible at the moment anyway, would not in any way affect the *file* that was loaded. Parsing a file is a read-only operation, so anything you do to the DOM once loaded has no effect whatsoever on the file. Naturally if you 'save' the DOM, then the file would be changed, but there's no reason to do that.
HTH