RE: [Xenocide-programming] XML interface

[Mamutas P. <ma...@pr...>]

Getting data from XML into DOM object would not cause any problems - any
DOM-supporting parser will have a method to do the whole work. The problem
here would be that the DOM object and methods to access its content would be
parser specific, if we would change the parser, we more likely need to
change the way we extract data from the DOM.

From what I remember now, I think it would be possible to limit number of
methods used to access data from DOM. That basically would allow us to write
a wrapper (or proxy?) class to access data from the DOM, which would contain
parser specific method calls. Or we can even put those methods inside of XML
loader itself.

So, here is an example:

Class XNetDBViewer access class XNetTechnologyTreeInformation.
Class XNetTechnologyTreeInformation exposes methods giving the all
information about technology tree. XMLLoader loads any XML file and stores
its content in memory in the DOM. XMLLoader is parser specific class.
XMLLoader exposes methods for general DOM navigation and information
retrieval. XNetTechnologyTreeInformation uses those methods to extract
necessary info about technology tree. Note that
XNetTechnologyTreeInformation does not store any info in memory, but reads
it out from the DOM.

So, in this example, if we will decide to change the parser, the only class
needs to be updated is XMLLoader. But, if we will decide to change the XML
format, the only class needs to be updated is XNetTechnologyTreeInformation.
XMLLoader does not care about content of the file.
XNetTechnologyTreeInformation does not care about parser used.

Regards,
mamutas

-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of Chris
Phillips
Sent: Thursday, March 25, 2004 3:27 PM
To: xen...@li...
Subject: Re: [Xenocide-programming] XML interface


That's along the lines of what I was thinking.  The
real tricky part is deciding how you store the data in
memory once it's loaded.  DOM modules seem to be
specific to Xerces and other parsers, so I'm not sure
if we'll be able to use this in outside classes.  As
far as I know there is no generic DOM class for C++
(am I wrong? - I hope I am..).  

This creates several difficult problems.  First,
loading everything into a DOM object and then from
that into another generic temporary storage object
which is then used to pass data into the actual object
is overly redundant.  Second, passing the DOM object
breaks the encapsulation we're trying for.  Third, we
may be more limited in terms of what functionality
we're able to use since we're doing an indirect
interface. 

So.. I'm still trying to figure out how we can make
this work..  The Xerces parser libs still don't work
for me (although most of the other Xerces libs do) so
that doesn't help.  I might just try and get something
like this working with expat, and someone else with a
Xerces comapatible system (most likely Windows) would
need to do a Xerces version. 

Regards,
chrisp

> I really favor that approach, what do you think
> about something like this:
> 
> class IExternalizable
> {
> public:
> 
>     // filename is the name without extension
>     void saveToFile ( String filename );
>     void loadFromFile ( String filename );
> };
> 
> Then we just have to reimplement the loading of
> every independent class
> that needs to be externalizable on its own.
> 
> Greetings
> Red Knight

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.616 / Virus Database: 395 - Release Date: 3/8/2004