Child pages
  • Overview-Key Value Coding
Skip to end of metadata
Go to start of metadata

Key-value coding is a way to separate interfaces and a way to flexibly access data and methods in object instances. The concept has a long history. It appeared in Eiffel, and other places as well. If you are familiar with OGNL then you will know it from there. We'll call key-value coding KVC in the context of this page to abbreviate. KVC also exists in the Cocoa infrastructure shipped with MacOS-X, having evolved from OPENSTEP and the development tools created for it. In this page we will focus on KVC in the context of WebObjects and java.

Conceptual Aspects

Consider the following model segment:

This model shows a number of entities and the lines between the entities show relationships. For example, the Organisation entity has a to-one relationship with a Worker called "workerAccount" and it also has a "to-many" relationship to "OrgRegion" called "orgRegions".

The term "instance" here is referring to a specific organisation. For example, "The Corn Flour Company" and "Aqua Breweries" might be instances of the Organisation entity.

Value For Key

An instance of an Organisation can supply values for the keys "address", "countryIso", "email" etc... and they will return a value for the key. It is essentially acting like an NSDictionary or a Map object. This is how data is extracted from an object.

Take Value For Key

This is where an instance of an entity is asked to "take up" some value for a key. For example, an instance of an organisation might be told to take the value "foo@foo.co.nz" for the key "email". This is how data is loaded into an object using KVC.

Value For Key Path

Using a dotted path, it is possible to traverse relationships to access data in other entities. For example, if you have an instance of "OrgExpertise", it is possible to get the value for the key path "organisation.workerAccount.name". This is how you can extract data from the interconnected network of object instances.

Take Value For Key Path

Using a dotted path, it is possible to get an object in the interconnected network of object instances to "take up" some piece of data. For example, if you have an instance of "OrgExpertise" then it is possible to get the object to "take up" a value of "Joe Smith" for the key path "organisation.workerAccount.name".

  • No labels

1 Comment

  1. This is some text I wrote a little quite ago to explain KVC to some colleagues. It introduces KVC in a non database context, which I think is a bit easier to get a grip on, but it doesn't fit the style of this page, hence added as a comment:


    One design pattern of WebObjects that is important to have a decent understanding of (and it's an understanding that gets deeper and deeper with experience) is "key-value coding" (KVC). It is a simple capability but lies at the heart of the WebObjects user interface code and at the heart of Enterprise Objects.

    It's the seeming magic that allows values to be pulled out of classes by only knowing their name (or key) – the code that tries six ways to get a value. When a class inherits this behavior it becomes a bit like a dictionary – you can ask a class for a VALUE when all you know is the KEY.

    Many classes in the WebObjects frameworks inherit this capability, with the result that you have classes that can exchange data at run time, though they had no knowledge of each other at compile time. Very powerful.

    You've seen this in a WOComponent: at run time as WebObjects is building the HTML to send back to the browser it keeps bumping into these <WEBOBJECT NAME=xxx> tags. As each tag is encountered the bindings in the definition file:

        xxx: WOString {
            value = countryOfBirth;
        }
    

    are used to expand the HTML. When the value of the WOString is being determined the component is interrogated using KVC for value of the key "countryOfBirth".

    In the Enterprise Object (EO) side of things where databases are managed, KVC is also used extensively. In simple terms EO's job is to transform a database row into a class - the columns of the row are accessed via KVC – that is, you tell the class to get the VALUE of the
    KEY which is the column name. So with the class Employee, for example, you get/set entries in the class (and ultimately, on a commit, the database) with keys like "firstName", "Salary", "Manager".

    But this gets really spooky with EO! In the HTML expansion, we have to supply a variable or write a getter method to satisfy the KVC hunt. In EO, you don't! Any class which represents rows in a database, inherits the KVC behavior, but for these classes (based on EOGenericRecord), in
    addition to the six getter methods, it can also return values directly from database rows already cached in memory.