On Aug 2, 2006, at 1:39 PM, Kevin Windham wrote:
I have some code that reads and writes my preferences to an XML
file. The writing code is pretty straight forward. It just travels
down the chain of classes that make up the data model for my prefs
and asks each class instance to add it's properties to the xml
document.
The reading code however is somewhat inelegant it seems. I am using
an XMLReader to parse the prefs file and it gives events for the
xml entities as it reads them in. So in order to let each class
instance handle it's own stuff, I have the XMLReader instance pass
those events to methods in the various prefs classes that mirror
the event in the XMLReader. Then each pref class has to determine
if the current xml entity belongs to it, or to a class it contains.
If it is a class contained in the current class, then the original
event is passed on to the contained class, and the cycle continues
down the chain. The code works fine, but it seems inelegant to be
duplicating all those event methods in each class. My instinct
tells me that there is a better way to handle this, but I haven't
come up with it yet.
Does anyone have any suggestions?
Based on some useful advice I have received here, I switched to using
the XMLDocument class for reading instead of the XMLReader class. I
guess I was a little confused about the two different methods of
reading in an XML file that RB offers.
Now that I have an XMLDocument to work with my reading code is very
similar to my writing code. I just pass the nodes down the chain to
each class so it can handle reading it's own values from the
XMLDocument. This combined with the xql that was suggested earlier
makes the code much cleaner and easier to maintain. I feel that it
would also be easier to abstract it out further if needed in the future.
Thanks for everyone's suggestions,
Kevin
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>