Synchronizing Parent and Child Components

WebObjects treats attribute bindings between parent and child components as potentially two-way communication paths and so synchronizes the values of the bound variables at strategic times during the request-response loop. This synchronization mechanism has some implications for how you design components.

For the sake of illustration, consider a page that displays a value in two different text fields--one provided by the parent component and one by the child:

Figure 1. Synchronized Components

Setting the value of either text field and submitting the change causes the new value to appear in both text fields.

The parent's declarations file reveals the binding between the two components:

CHILDCOMPONENT: ChildComponent {
    childValue=parentValue;
};

When a value is entered in a field and the change submitted, WebObjects will, if needed, synchronize the value in the parent (parentValue) and child (childValue) at each of the three stages of the request-response loop:

Before and after the components receive the takeValuesFromRequest:inContext: message.
Before and after the components receive the invokeAction:inContext: message.
Before and after the components receive the appendToResponse:inContext: message.

Synchronization is accomplished through key-value coding, a standard interface for accessing an object's properties either through methods designed for that purpose or directly through its instance variables. (The key-value coding mechanism is declared in the Enterprise Objects Framework, in EOKeyValueCoding.h. See the Enterprise Objects Framework Developer's Guide for more information.) Key-value coding always first attempts to set properties through accessor methods, only reverting to accessing the instance variables directly if the required accessor method is missing.

Given that synchronization occurs several times during each cycle of the request-response loop and that key-value coding is used to accomplish this synchronization, how does this affect for the design of reusable component? It has these implications:

You rarely need to implement accessor methods for your component's instance variables. For instance, it's sufficient in the example above to simply declare a childValue instance variable in the child component and a parentValue instance variable in the parent. You only need to implement accessor methods (such as setChildValue: and childValue) if the component must do some calculation (say, determine how long the application has been running) before returning the value.
If you do provide accessor methods, they should have no unwanted side effects and should be implemented as efficiently as possible since they will be invoked several times per transaction.
If you bind a component's attribute to a method rather than to an instance variable, you must provide both accessor methods: one to set the value and one to return it. Let's say the parent component in the example above doesn't have a discrete parentValue instance variable but instead stores the value in some other way (for example, as an entry in an NSDictionary object). In that case, the parent component must provide both a parentValue method (to retrieve the value) AND a setParentValue: method (to set it). During synchronization, WebObjects expects both methods to be present and will raise an exception if one is missing.

Table of Contents Next Section