# Programming with XML - usage questions (C++)

This topic is 4776 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm working on a project that makes heavy use of XML for both an internal data format and data storage. There are a good number of objects that have a fairly static depth to them, so tree walking would not be neccisary. My question is if I should write the classes for those objects with specific accessor methods or constant pointers to the nodes that contain the data, for easier and faster access (mostly just for cleaner code). There are four approaches I've thought of. 1) just leave it alone, code in all the domdocument access where needed (extra code, gah), 2) Accessor methods as part of the class that return data of a type thats usefull instead of domnodes and the like. 3) code in pointers that stay pointed to the domelement of each value I want to monitor (would still have to convert to types that can be useful) 4) code generic accessor methods that return a (usefull) value by name Here's some simple prototype examples of the last three:
class object
{
public:
string getName();
int getWeight();
DOMDocument * theObject;
};

/* --------------------------------------------------- */

class object
{
public:
string getStrValue(string elementName);
int getIntValue(string elementName);
DOMDocument * theObject;
};

/* --------------------------------------------------- */

class object
{
public:
DOMElement * namePtr;
DOMElement * weightPtr;
DOMDocument * theObject;
};


How do most of you handle your XML data? Do you find it easier to write accessors, or leave the XML alone? Do you find it usefull as a file format, but load it into custom data structures when you use it? All opinions welcome, thanks ahead of time!

##### Share on other sites
I've been using XML in one of my projects, but I'm thinking of dropping it for a Lua based design.

Anyways, heres what I do, I use Expat first off, really easy to use. Next, I have a nested switch-cases. This emulates the tree, which should be fairly static, I.E. codes only work nested and n levels in. Then, I just do string parsing, since I've reduced it enough that I can wastefully afford it.

As for any data that would extend a bit beyond xml, such as binary data, I was thinking Base64, which isn't a big waste because the files were going to be compressed by zlib. For my purposes, this would have worked fine. Though, on larger files, you'd start to build a load time. This solution is not for everyone.

Anyways, switching to lua, I'd probably still use the base64 and zlib solution, but now just write the scripts smartly.

##### Share on other sites
The classes shouldn't expose their data source, so I'm going for option #4. It seems like coding to a DOM implementation is a bit overkill if you're going to be dealing with simple data structures.

##### Share on other sites
Quote:
 Original post by igni ferroqueThe classes shouldn't expose their data source, so I'm going for option #4. It seems like coding to a DOM implementation is a bit overkill if you're going to be dealing with simple data structures.

I'm -way- simplfying the project as whole in this example, the data structures themselves can get incredibly complex, with no defined limit to the number of steps up the tree (although in many cases, the tree can be compacted by references instead of entire elements). But certain small xml objects are going to be used a lot in code, and accessed very often, I was just trying to find if it's worth the effort to change how they're handled from the rest of the code and xml objects. The actual "simple" objects I'm thinking about have around 30 or so elements, with data nested in some of them 2 or 3 levels deep. I was just thinking that writting some accessors for some of those data entries might speed up the engine as a whole in some cases.

As for the engine, we'd looked into Expat during the initial design phase, but settled on Xerces after a bit of poking around. It's not exactly a lightweight xml system, but we're not sending it lightweight data.

Thanks for the input folks =)

• 9
• 23
• 10
• 19