A very long time ago I put in a simple plist reader to the BKHashTree so that I could read in the plist files off my Mac OS X system into a map of maps, as the BKHashTree is, and display them in a nice graphical tool that I was building. The GUI widget I created has found a lot of use in the code I've written over the years, and when talking to a fellow developer late yesterday it was clear that what we might really need was a full-featured plist reader. I remembered something about this, looked it up, and sure enough, I had the basics of this already coded up. While he had found something that looked to have all we needed, it had somethings we didn't need, and I wanted to take a shot at cleaning up the reader I'd made, add a writer, and augment the data types allowed in the plist file.
The first thing that was missing in my code was the list/array element. Basically, we wanted to be able to provide the user the ability to specify a list (Java ArrayList) of elements as simply as possible:
{
names = (Bob, Fred, John);
}
It was pretty easy to see that the simplest way was to process the array as a single argument (value, in this case) to the routine that I had that picked the correct object type of the element and made it available for placement in the Map. This worked for a while, but pretty soon I ran into serious limitations. What I needed to realize is that the array processing is very similar to the map processing - just with a series of values as opposed to a series of keys and values.
This was a major simplification in the code. I had a map processor and an array processor and they called each other. Should one of the elements of an array be a map, it passed control over to the map processor, which returned a Map to place in the array. Likewise, if the map processor hit upon an array it sent the code over to the array processor which returned an array that would be used as either the key or the value. Very nice. It was only at the very lowest level that we needed to look at the elements and determine the data type they were.
The next thing to do was to add in the URL and binary data types. The URL was pretty easy - it's a string with '://' in it and no spaces. The binary data was a string starting with '0x' contained within <> like this:
{
password = <0x347ab0ef21>
}
There's still the limitation that there can't be a space after the '<' and before the '0x' because the BKData needs to look at the string it's given as starting with '0x', but that's something that I can fix without too much trouble - should it become a real issue. Right now, I can't imagine what we'd use the binary data for except passwords, and those we wouldn't be hand-edting because they'd probably be encrypted or at least Base64'ed.
The final thing I worked on today was the writing of the data and while the writing itself was easy, making it look decent when written wasn't. I tried to balance the ideas of putting individual items on a different line and making it look more readable by putting small arrays, etc. on the same line. I know it's not perfect, but it's very readable now and that's enough. It's not meant to be a beautiful output- only functional.
This all got started because we wanted to have a distributed Preferences system in Java that didn't have the current limitations that the current crop of Preferences Factories has in Java. More on that tomorrow.
