PATH  WebObjects 4.0 Documentation > EOF Developer's Guide

Table of Contents Previous Section

How Changes are Distributed and Applied

 An EOEditingContext is responsible for managing the changes that occur to the objects in its object graph. For example, suppose the user edits a value in the user interface in an Application Kit application. This causes the sequence of events illustrated in Figure 51.

Figure 51. Flow of Events When a User Edits Data

When a user edits data in the user interface:

  1. The EOAssociation passes the new value to its EODisplayGroup.

  2. The display group applies the changes to the affected enterprise object.

  3. The enterprise object notifies the EOEditingContext that it has changed. Specifically, the enterprise object invokes its willChange method, which in turn invokes the editing context's objectWillChange method (objectWillChange: in Objective-C).

  4. The editing context records the object in its list of unprocessed changes. (How the editing context manages these changes is described in "How an EOEditingContext Manages Changes to Its Objects".)
Then, at the end of the event loop:

  1. The editing context records undos.

  2. The editing context broadcasts an ObjectsChangedInStoreNotification and an ObjectsChangedInEditingContextNotification (EOObjectsChangedInStoreNotification and EOObjectsChangedInEditingContextNotification in Objective-C).

  3. The display group, which is registered to observe the ObjectsChangedInEditingContextNotification, receives the notification and updates the user interface.

  4. All views of the data in the application refresh themselves to reflect the change.

Customizing Framework Behavior

 During this process, you can customize the behavior of the EOEditingContext by registering for the following notifications and taking the appropriate action.
EOEditingContext Notifications
Notification Description
ObjectsChangedInStoreNotification (EOObjectsChangedInStoreNotification in Objective-C) This notification is broadcast whenever objectWillChange observer notifications are processed, which is usually at the end of the event in which the changes occurred.
ObjectsChangedInEditingContextNotification (EOObjectsChangedInEditingContextNotification in Objective-C) This notification is broadcast whenever changes are made in an EOEditingContext. It's similar to EOObjectsChangedInStoreNotification, except that it contains objects rather than globalIDs. EODisplayGroups listen for this notification to redisplay their contents.

How an EOEditingContext Manages Changes to Its Objects

From the standpoint of an EOEditingContext, the changes you make to objects in an application fall into one of three categories:

Normally, when an editing context's objects change (for example, when they're deleted or their data is modified), the processing of changes is deferred until the end of the current event. In the meantime, the editing context buffers pending insertions, deletions, and updates as unprocessed changes.

Note: When a source (master) object has an owning relationship to a destination object (as determined from the EOClassDescription) and the destination object is removed from the master, the destination object is marked for deletion from the EOEditingContext. For example, if a purchase order owns a line item and the line item is removed from the purchase order, the line item is marked for deletion from the editing context since the owning relationship implies that a line item can't exist without a purchase order.

When an EOEditingContext processes changes, typically at the end of an event, it does the following to the objects in its unprocessed changes list:

  1. Processes deleted objects.

    For a more detailed description of what this entails, see the following section, "How Deleted Objects are Processed."

  2. Moves each object to the context's inserted, deleted, or updated list, as appropriate.

  3. Snapshots the objects for undo.

  4. Posts ObjectsChangedInStoreNotification and ObjectsChangedInEditingContextNotification.

How Deleted Objects are Processed

 Just like inserted and updated objects, deleted objects are normally processed at the end of the event in which the change was made. However, you can use the method setPropagatesDeletesAtEndOfEvent (setPropagatesDeletesAtEndOfEvent: in Objective-C) to change this behavior so that the editing context only processes deletions right before you save to the database.

The processing of deleted objects entails these steps:

  1. Deletions are propagated by sending each object a propagateDeleteWithEditingContext message (propagateDeleteWithEditingContext: in Objective-C), which then invokes the EOClassDescription method propagateDeleteForObject (propagateDeleteForObject:editingContext: in Objective-C). By default, this method applies the delete rule of every relationship (Deny, Nullify, Cascade) to the source object's child objects.

  2. The deletion is validated by sending each object the message validateForDelete.

    By default, each object forwards this message to its EOClassDescription. Based on the result, the operation is either allowed or refused. For example, referential integrity constraints in your model might state that you can't delete a Department object that still has employees. If a user attempts to delete a department that has employees, the deletion is refused. An enterprise object class can also implement its own version of validateForDelete to do some additional processing before passing the check on to its EOClassDescription. For more discussion of validation, see the chapter "Designing Enterprise Objects".

Instead of waiting until the end of the event, you can force the processing of inserted, updated, and deleted objects by invoking the EOEditingContext method processRecentChanges. EOEditingContext invokes this method on itself before performing certain operations such as saveChanges. The sequence of events that occurs when an editing context receives the message saveChanges is described in the next section.

Table of Contents Next Section