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:
Unknown macro: noformat. Click on this message for details.
The [noformat] macro is not in the list of registered macros. Verify the spelling or contact your administrator.
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.
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:
Unknown macro: noformat. Click on this message for details.
The [noformat] macro is not in the list of registered macros. Verify the spelling or contact your administrator.
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.