One of the NNTP commands I wanted to implement in Wombat was XPAT. XPAT is a simple search command that searches a specified header on a range of messages for a given wildmat expression. For example:


XPAT subject 1-12 *fred*

searches messages 1 through 12 for any message that has a subject containing the word “fred.” Matching a given header against a wildmat expression (i.e. the *fred* in the previous example), was easy because wildmat expressions are easily convertible into regular expressions. The problem was the user could specify any header to search against.

Although NNTP specifies a group of standard headers, posts are not limited to those standard headers. Any header, as long as they are syntactically correct, can be added to a message. What’s more, each message is going to have a different set of headers. The first message might have an X-NNTP-Posting-Agent header, while the second one might not.

Since headers vary from post to post, and could be almost innumerable, I couldn’t add them to my Post entity as persistent attributes. Instead, I have one attribute, headers, which is a string with each header on its own line.

This caused a problem because I wanted to use NSPredicate’s MATCHES operator to compare a specific header against a regular expression. I wanted to specify the predicate query as:


subject MATCHES ".*fred.*"

Unfortunately NSPredicate wants an attribute name to compare against (subject in this case), and my NSManagedObject didn’t have one. It had the headers attribute, but that contained all the headers, not just one. Since, once again, the headers can vary, I needed a way to dynamically add transient attributes to my NSManagedObject derived class, Post.

Since NSPredicate uses Key Value Coding to obtain the value of an attribute, I figured there was a solution. My first thought was to simply overload valueForKey: on my Post class. However, I was worried I’d muck up the Key Value Coding mechanism, and break something important. Fortunately, by digging through the Key Value Coding documentation I discovered the valueForUndefinedKey: message. According to the documentation, if a key wasn’t found via the normal means, the valueForUndefinedKey: message was called. This is important because that means if I overload valueForUndefinedKey:, I don’t run the risk of masking built-in, and possibly important, keys.

By default, valueForUndefinedKey: simply throws an exception stating no such attribute exists. This is valid behavior that I wanted to keep when overloading it. However, on the other hand, no matter what header the client asked for, I had to pretend that it was there and at least return an empty string. This was on the chance that some of the messages had the header. In other words, I needed a way to determine if the caller of valueForKey: was just asking for Joe Random attribute or a header attribute.

The only easy way I came up with was to prepend header attributes with a common prefix, like “header_”. So the NSPredicate query above becomes:


header_subject MATCHES ".*fred.*"

This makes the processing in valueForUndefinedKey: pretty easy. The method, in general, can be defined as:


- (id)valueForUndefinedKey:(NSString *)key
{
if ( [key hasPrefix:@"header_"] )
return [self headerForName:key];

return [super valueForUndefinedKey:key];
}

As you can see, determining valid header requests from invalid attribute requests is easy. I call the super’s implementation of valueForUndefinedKey: so that the exception is thrown, as expected, in the case of bad attribute requests. Also it means that if the parent class does something other than throw in the future, that it will continue to work.

I have to admit this was much easier to implement than I thought it would be. I also like the idea that I can easily access all my header values via NSPredicate, which is very useful.