Boris Koenig wrote:
I have now looked into dozens of source files, but I don't seem to be
able to find those files that are responsible for the XML handling,
respectively loading & parsing the PropertyList XML files, so I apologize in advance, but: what's the name of the classes that are used
or rather where do I have to look for this stuff ?
(I simply want to use FG's XML-handling capabilities for a specific function)
XML : SimGear/simgear/xml/easyxml.?xx Property Tree: SimGear/simgear/props/props_io.?xx
Thanks Erik !
> Do you want to parse XML yourself, or rather read an XML file into a > property tree?
Actually, preferably only the second - this is something that we talked about a couple of weeks ago: I asked you whether there would be any way to deal with XML files in Nasal, (because I wanted to be able to dynamically populate my Nasal-creted PUI controls using data taken from XML -files) you said there wouldn't yet be any way to do this and that this would require some thinking.
So I thought about ways to achieve this while keeping things simple- in order to keep the overall overhead to a minimum level - after all I don't need to use direct I/O in Nasal, so that's what I've come up with:
Two additional fgcommands to be called by Nasal
fgWriteXML (SGPropertyNode * sourcepath, char *filename); fgLoadXML (SGPropertyNode * targetpath, char *filename);
=> The first takes a path to a node within the property tree and iterates through it, in order to write all its elements to the file specified by 'filename'.
=> The second one loads the file specified by 'filename' and make all of its contents available within the property tree path specified by 'targetpath'.
Of course this is not yet particularly elegant and might cause problems when it comes to XML files that exceed a certain size, cause they would simply be dumped into the property tree ...
But for the near future it would probably be perfectly suitable for my purposes.
Later on, one might still consider an approach such as the one that Jim & Norman brought up yesterday in the "/sim/navdb" - thread, e.g. by only exporting the *indexes* (i.e. toplevel nodes) of nested data to the property tree and making data only available upon really ACCESSING a node.
That way the memory usage would be kept to a minimum and only those nodes would really consume memory that are really accessed - the wrapper that Jim mentioned is certainly not such bad idea, because something like this could generally be used to minimize memory consumption by nodes that are not accessed a certain amout of times within a particular timespan - so a node would be classified depending on the amount of times it is accessed ... but that's a different matter.
Regarding the specification of the filename for the XML loading mechanism, I've now also modified Andy's dialog.cxx to also support PUI's puFileSelector widget, so that you can easily create a corresponding PUI dialog with such a widget to ask a user to pick a certain file, the path/filename is then also stored within a temporary property tree node, like "/tmp/filename";
So, for now these are the types of modifications that I would like to see added within the next time. I'm going to send you the modifications as diff files by private eMail.
Most of this is not really a big change to FG itself - but could still come in very handy - e.g. XML handling functionality for Nasal would also mean that PUI dialogs could suddenly offer users to PRESERVE settings/customizations - this is something that's currently not yet possible.
Even though I have to admit that I am not yet fully sure about how to implement the PropertyTree Node -> XML file mechanism (and vice versa).
It's not so much a logical problem, but rather I was hoping to get some insight about how FG handles these things from the code that's used to parse the PropertyList structures for all the other stuff - otherwise I would probably have to use some other XML-parser ...
So, I might very well have to ask about one thing or another ;-)
Cause, essentially I would prefer to use FG's inbuilt mechanisms - it
doesn't matter whether these items are then stored within a <PropertyList> tags or not, in the end it would probably not only save
some work and time, but also resemble reality - simply because what's
getting stored in these files IS indeed going to be a property list.
Sorry again, for the long posting, Erik ;-)
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d