Oh, one more thing, it’s minor but sort of interesting: My configuration files were getting confusing now because they now have to be shared between the record and the replay application, so I took a few hours to write a small XML configuration class.
The configuration data isn’t accessed by manually traversing a tree. Instead, you specify the path to the node or attribute. I got this idea from the Perforce-style patterns and a project about DOM path blocking in Firefox that Justin Crites and I did a year ago.
Assume there is an XML file with the following contents:
Nodes are specified using a slash (/) as separator: Then the path “foo/bar” retrieves the string “abc”, and the path “foo/fum” retrieves “def”. There may be only
#comment nodes in the node specified by the path. All
#text nodes will be concatenated and then stripped of whitespace at the beginning and the end.
Attributes are accessed by specifying the containing node and the attribute name, separated by a dot (.): The path “foo/fum.fee” refers to the value “xyz”, and the path “foo.a” refers to the value “uvw”.
Only strings can be stored and retrieved this way. If I wanted to store more complex data with internal structure, I would either have to convert it to a string and then parse it again, or write more complex functions to handle XML. For now, though, this is sufficient and very convenient.
Later, these XML functions may be thrown away again. DrJava uses a Scheme-like syntax for configuration files, if I remember correctly. But regardless, I like my configuration class and it didn’t take long to write.