EOKeyValueCoding

By Sam Krishna and Patrick Taylor

Throughout this series we've asserted that programming in WebObjects is a richer, more mature experience than any competing web application development environment. A major reason for this superior programming experience can be laid at the feet of EOKeyValueCoding.

EOKeyValueCoding is simultaneously a powerful protocol (in Objective C) and interface (in Java). When the EOControl framework is imported, all Objective C classes that inherit from NSObject receive EOKeyValueCoding behavior. (The EOControl framework is imported automatically into WebObjects apps and frameworks. You do not have to explicitly import it in to your WebObjects app or framework project.) In Java, when the developer creates a subclass of EOEnterpriseObject, EOCustomObject, EOGenericRecord or WOComponent, then EOKeyValueCoding is available.

What is remarkable about EOKeyValueCoding is how universally powerful it is. With this protocol/interface, the WebObjects and EOF frameworks know how to access custom instance variables (ivars) from within your subclass. Using the methods valueForKey() and takeValueForKey() (in Objective C valueForKey: and takeValue:forKey:) WOF and EOF can access your ivars through standard API. In addition, EOKeyValueCoding provides the bridge within EOF for effective entity-relationship mapping.

In valueForKey(), this standard method allows a lookup of an ivar from both WOF and EOF classes. Consider a WOComponent subclass that needs to fill in the value of a String object in the dynamic WOString element. The WOString is bound to lastName of an EnterpriseObject (EO) which represent the employees of a corporation.

1. The component subclass searches for a public accessor method based on the key name. With a key of "lastName", valueForKey() looks for a method named getLastName() or lastName(). In Objective C, it looks for a method named getLastName or -lastName.
2. If a public accessor method isn't found, the component subclass searches for a private accessor method based on key. Note that traditionally in the Apple frameworks, a private method is distinguished by a preceding underbar. In this case, valueForKey() looks for a method named _getLastName() or _lastName(). In Objective C, it looks for a method named _getLastName or -_lastName.
3. If an accessor method isn't found and the class method accessInstanceVariablesDirectly returns true (in Java) or YES (in Objective C), valueForKey() searches for an ivar based on the key name and returns its value directly. For the key "lastName", this would be _lastName or lastName.
4. If neither an accessor method or an ivar is found, the default implementation invokes handleQueryWithUnboundKey() in Java or handleQueryWithUnboundKey: in Objective C. The default implementation of this method will raise an NSException.

Sometimes exceptions are raised because although ivars have changed or been deleted for some reason the component subclass or the frameworks still expect the ivar to exist unchanged. In these situations after 10-15 minutes of proverbial pounding sand, we would override handleQueryWithUnboundKey() and check to see if the disputed ivar is being looked up, and if so, return nil or null.

For another example, suppose that you have an EO using a BigDecimal or NSDecimalNumber with "someDecimal" as one of its ivars.

(BigDecimal)myEO.valueForKey("someDecimal");
note: you must always downcast your objects when using valueForKey() in Java

[myEO valueForKey:@"someDecimal"];
Here is the operational order for takeValueForKey() (takeValue:forKey: in Objective C)

1. The EOKeyValueCoding methods search for a public accessor method of the form setKey (setKey: in Objective C)
2. If a public accessor method isn't found, EOKeyValueCoding searches for a private accessor method of the form _setKey (Objective C _setKey:) invoking it if such a method exists
3. If an accessor method isn't found and the class method accessInstanceVariablesDirectly returns true or YES, takeValueForKey() searches for an ivar based on the expected key name and sets the value directly in Java. In Objective C, the old value is autoreleased and the new one is retained. For the key "lastName", this would be _lastName or lastName.
4. If neither an accessor method or an ivar is found, the default implementation invokes handleTakeValueForUnboundKey in Java and handleTakeValue:forUnboundKey: in Objective C.

It is important that while this method has been very well debugged, sometimes phantom keys can be looked up long after they "died". It is prudent to override handleTakeValueForUnboundKey in this situation to check if the phantom key is being looked up and, if so, do nothing.

What are Protocols and Interfaces?

Objective-C protocols and Java interfaces represent essentially the same object-oriented concept: the ability to declare methods that are independent of a particular class and can be implemented by classes in any heirarchy. Any Objective-C class that declares itself to conform to a particular protocol or Java class that implements a particular interface must, by default, implement the methods declared by that protocol/interface. The approaches taken are different with the Objective C approach being arguably more flexible.

Confused? Don't worry — maybe an analogy can make things clearer. Imagine you're writing a nature simulation program which requires that various "animals" have a swimming behavior. Since entirely different kinds of animals can share behaviors even if they come from entirely different species, phyla or families, not every swimming creature inherits from the same class (whales, trout, dogs and humans are all "swimmers" even though they inherit from different classes of "animal": whales do not inherit from trout because whales are mammals while trout are fish, dogs do not inherit from humans because dogs are canines while humans are primates, etc).

In your swimming simulation, you need to have your objects implement a specific type of behavior, but not necessarily the same way. You also want to show what happens when certain types of animals are not able to swim in water (like most species of birds, for example). So, if you are writing an Objective C program, you declare a 'Swimming' protocol. Correspondingly, if you are writing a Java program, you declare a 'Swimming' interface.

The Objective-C protocol declaration may look like this:

@protocol Swimming

- (void)treadWater;
- (void)swimFreestyle;
- (void)breathe;
....

@end

The Java interface declaration may look like this:

public interface Swimming {
    public void treadWater();
    public void swimFreestyle();
    public void breathe();
    ....
}

In the swimming simulation, dogs, humans, whales, trout and ducks implement the Swimming protocol or interface method declarations and would swim in ways unique to those species. A hummingbird, on the other hand, would probably not implement the Swimming protocol or interface, and therefore drown if left in water for a prolonged period of time.

To set the ivar 'someDecimal' to a BigDecimal object of value '1', you would:

myEO.takeValueForKey(new BigDecimal("1"), "someDecimal);

[myEO takeValue:[NSDecimalNumber decimalNumberWithString:@"1"] forKey:@"someDecimal"]

What happens when your code accesses ivars that no longer exist?

This is an interesting situation. Most often, this occurs when a developer has removed an ivar from his EO without deleting all references to it from the code. EOF's default behavior is to invoke handleQueryWithUnboundKey in Java and handleQueryWithUnboundKey: in Objective C which throws an exception. Developers can override this if they desire some other behavior or have it fail gracefully (not at all recommended but if it is absolutely necessary ... ).

Corollary behavior occurs when using takeValueForKey (Objective C takeValue:forKey:)on an ivar that doesn't exist. EOF automatically invokes the method handleTakeValueForUnboundKey (Objective C handleTakeValue:forUnboundKey:). There are methods used as private API within EOF that are publicly exposed. storedValueForKey and takeStoredValueForKey in Java (storedValueForKey: and takeStoredValue:forKey: in Objective C) are used to access and/or initialize the receiver's values as they are stored in the database.

There are some methods in EOKeyValueCoding that make life considerably easier to get things done. And in the case of Objective C, it provides a very convenient way to implement the NSCoding protocol within a class.

valueForKeyPath (Objective C valueForKeyPath:) allows you to return the value at the end of a relationship path's property. For example, if you wanted to find the name of anEmployee's department, you would:

Java

(String)anEmployee.valueForKeyPath("department.name");

[anEmployee valueForKeyPath:@"department.name"];

The relationship from anEmployee to its department was traversed and the department's name accessed. Having done this, you can use another method takeValueForKeyPath (Objective C takeValue:forKeyPath:) to set the name of a relationship's property. To change the name of anEmployee's department:

Java

anEmployee.takeValueForKeyPath("Data Processing","department.name");

[anEmployee takeValue:@"Data Processing: forKeyPath:@"department.name"];

valuesForKeys (Objective C valuesForKeys:) returns an NSDictionary of the key-value pairs of an object. It's corollary method takeValuesFromDictionary (Objective C takeValuesFromDictionary:) sets the ivars of an object to the values of the NSDictionary passed as an argument.

What are Ivars/Instance Variables?

Instance variables (also known as ivars) are the specific variables of data for an object instance. What does that mean?

Let's say you have an Employee class which generically defines what an employee looks like. An Employee has a first name, a last name, and a Social Security number. In Objective C, an Employee would look like this:

@interface Employee : NSObject
{
    NSString *firstName;
    NSString *lastName;
    NSString *ssn;
}
....
@end

And in Java, an Employee would look like this:

public class Employee extends Object {
    protected String firstName;
    protected String lastName;
    protected String ssn;
    ....
}

Employee objects, like the employees that represent the CEO and the vice-president, would have a firstName, lastName, and an ssn instance variable. For the CEO, her instance variables might look like this: firstName = "Jane", lastName = "Smith", ssn = "555-12-1234". For the vice-president, his instance variables may look like this: firstName = "John", lastName = "Brown", ssn = "555-12-9876". For the CEO Employee object, its variables contain unique data, and likewise for the vice-president Employee object as well.

EOKeyValueCoding provides a consistent API for the frameworks to access the ivars for the retrieval and modification of data. Whenever a firstName is displayed on a web page in a WebObjects app, it is retrieved through EOKeyValueCoding's APIs. The corresponding modification of ivars occurs through EOKeyValueCoding's APIs on all objects. This consistency allows developers to create applications and frameworks faster because they don't have to think about how the ivars need to be accessed.

These methods can be used to quickly implement the NSCoding protocol in Objective C. The NSCoding protocol can be used to make an object archivable to disk. It consists of two methods encodeWithCoder: and initWithCoder:. Imagining a situation where a developer wished to implement an Employee class that didn't use EOF. Some form of persistence needs to be created for the Employee objects by implementing the NSCoder protocol.

Implementing persistence

Employee.h
#import <Foundation/Foundation.h>
@interface Employee : NSObject <NSCoding>
{
    NSString *firstName;
    NSString *lastName;
    NSString *ssn;
    NSString *streetAddressOne;
    NSString *streetAddressTwo;
    NSString *city;
    NSString *state;
    NSString *zipCode;
    NSDecimalNumber *salary;
}

//  Skip the accessors....

//  EOKeyValueCoding-based methods
- (NSDictionary *)objectAsDictionary;
- (NSArray *)attributeNames;

//  NSCoding methods (which we declare for this example...)
- (id)initWithCoder:(NSCoder *)coder;
- (void)encodeWithCoder:(NSCoder *)coder;

@end

Employee.m
#import "Employee.h"
#import <EOControl/EOKeyValueCoding.h>

@implementation Employee

//  EOKeyValueCoding-based methods
- (NSArray *)attributeNames
{
    //  Return the ivar 'keys' in an NSArray
    return [NSArray arrayWithObjects:
         @"firstName",
         @"lastName",
         @"ssn",
         @"streetAddressOne",
         @"streetAddressTwo",
         @"city",
         @"state",
         @"zipCode",
         @"salary",
        nil];
}

- (NSDictionary *)objectAsDictionary
{
    //  Return the object as an NSDictionary, using the -attributeNames
    //  method to define the keys of the object
    return [self valuesForKeys:[self attributeNames]];
}

- (NSString *)description
{
    //  Inherited from NSObject
    //  Represent the object as an NSDictionary
    return [[self objectAsDictionary] description];
}

//  NSCoding methods
- (void)encodeWithCoder:(NSCoder *)coder
{
    //  NSDictionary already conforms to the NSCoding protocol,  as
    //  well as NSString and NSDecimalNumber
    [super encodeWithCoder:coder];
    [coder encodeObject:[self objectAsDictionary]];
    
    return;
}

- (id)initWithCoder:(NSCoder *)coder
{
    NSDictionary *newSelf;
    
    self = [super initWithCoder:coder];
    newSelf = [coder decodeObject];
    
    //  Since we've already archived ourselves as an NSDictionary,
    //  we can probably take our values from the decoded NSDictionary
    [self takeValuesFromDictionary:newSelf];
    
    return self;
}

@end

This is a simpler (and faster) way of implementing NSCoder, particularly as the number of ivars increasses. In our example, the traditional approach would have required 10-12 additional lines of code for dealing with all of the ivars individually. Instead of all that, the object is archived as an NSDictionary and the EOKeyValueCoding protocol takes care of the rest.

EOKeyValueCoding provides a consistent and convenient API to access and manipulate all of your ivars within your objects. It also provides a uniform way to represent all objects as NSDictionaries to WebObjects and EOF. This helps make object-oriented programming within WebObjects much simpler which is beneficial regardless of your level of expertise.

Unsurprisingly, EOKeyValueCoding is too useful to be kept to EOF and WebObjects alone. Apple recognized its potential by migrating it for JavaClient as NSKeyValueCoding. Even more significant, NSKeyValueCoding appears to be moving into Foundation for use with Cocoa programming. Other than some source code #import changes, all the API stays consistent which now means that persistence within classes will become much simpler.

Please feel free to contact the authors with questions or comments on the articles at webobjectseof@mac.com. We may not be able to reply personally to all emails but every one will be read.