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>

Reply via email to