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
- The EOAssociation passes the new value to its EODisplayGroup.
- The display group applies the changes to the affected enterprise object.
- 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).
- 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".)
- The editing context records undos.
- The editing context broadcasts an ObjectsChangedInStoreNotification and an ObjectsChangedInEditingContextNotification (EOObjectsChangedInStoreNotification and EOObjectsChangedInEditingContextNotification in Objective-C).
- The display group, which is registered to observe the ObjectsChangedInEditingContextNotification, receives the notification and updates the user interface.
- 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.
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:
- Insertion of a new object
- Deletion of an existing object
- Modification (updating) of an existing object
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:
- Processes deleted objects.
- Moves each object to the context's inserted, deleted, or updated list, as appropriate.
- Snapshots the objects for undo.
- Posts ObjectsChangedInStoreNotification and ObjectsChangedInEditingContextNotification.
For a more detailed description of what this entails, see the following section, "How Deleted Objects are Processed."
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:
- 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.
- 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".
Table of Contents Next Section