[an error occurred while processing this directive] PATH Documentation > WebObjects 4.5 > EOF Developer's Guide

Editing Context Configurations

Recall that by default, each nib has its own EOEditingContext and that nibs share an EOObjectStoreCoordinator (see "Sharing Editing Contexts and Coordinators"). In this default configuration, each peer editing context has its own object graph. So for example, a single database row can be represented by separate enterprise object instances in different editing contexts. Changes to an object in one editing context don't affect the corresponding object in another editing context until all changes are successfully saved through their shared EOObjectStoreCoordinator. At that time the objects in all editing contexts are synchronized with the committed changes.

This arrangement is useful when an application allows the user to edit multiple independent documents. For example, imagine an Application Kit application that creates and modifies video rental records. Each rental is represented by a window that is loaded from the same nib.

You can implement variations on the default configuration to:

Use one EOEditingContext for multiple nibs.
In this scenario, multiple nibs have the same object graph and therefore see each other's changes to objects immediately.
Use nested EOEditingContexts.
This configuration is useful in a "drill down" user interface where, for example, changes in a nested dialog box can be okayed or canceled.

Using One Editing Context for Multiple Nibs

Ordinarily, changes to objects in one EOEditingContext aren't immediately reflected in the objects of another editing context. Figure 40 shows how this plays out in an application.

Figure 40. Different Nibs Use Different EOEditingContexts

In an application where changes in Window 1 should be immediately reflected in Window 2, both nibs should use the same editing context.

To use one editing context for multiple nibs, use the EOEditingContext static method setSubstitutionEditingContext (the setSubstitutionEditingContext: class method in Objective-C). You use this method to substitute the specified editing context for the one associated with a nib file you're about to load. This method causes all of the connections in your nib file to be redirected to the specified editing context.

For example, if Nib 1 in the figure above is loaded before Nib 2, you could invoke the following code before loading Nib 2 to set its EOEditingContext to the same one in Nib 1.

In Java:

EODisplayGroup displayGroup;

	// Assume that displayGroup is the display group

	// from Nib 1 and that Nib 1 has already been loaded.

EOEditingContext editingContext;



editingContext = 
displayGroup.dataSource().editingContext();

EOEditingContext.setSubstitutionEditingContext(editingCo
ntext);

NSApplication.loadNibNamed("Nib2", this);



// Restore the default behavior

EOEditingContext.setSubstitutionEditingContext(null);

In Objective-C:

EODisplayGroup *displayGroup;

	// Assume that displayGroup is the display group

	// from Nib 1 and that Nib 1 has already been loaded.

EOEditingContext *editingContext;



editingContext = [[displayGroup dataSource] 
editingContext];

[EOEditingContext 
setSubstitutionEditingContext:editingContext];

[NSApplication loadNibNamed:@"Nib2" owner:self];



// Restore the default behavior

[EOEditingContext setSubstitutionEditingContext:nil];

After loading a nib with a substitution editing context, you should restore the default behavior by setting the substitution editing context to null (nil in Objective-C). Then when nibs are loaded in the future, their editing contexts are simply unarchived and aren't replaced.

Using Nested Editing Contexts

EOEditingContexts can be nested, allowing a user to make edits to an object graph in one editing context and then discard or commit those changes to another object graph (which, in turn, may commit them to an external store). For example, Figure 41 shows a drill-down user interface that can be implemented with nested editing contexts. Before users save rental information, they can supply optional comments about the rental. Canceling the Comments panel reverts the rental to its pre-comments state. Okaying the Comments panel incorporates the comments into the rental.

Figure 41. A Drill-Down User Interface

To implement the drill-down behavior of this interface, the editing context for the Comments window sits on top of the Rental window's editing context as shown in Figure 42. In this configuration, the Rental window's editing context is the parent object store of the Comment's editing context.

Figure 42. Nested Editing Context Configuration

To set up a nested editing context configuration, use the EOEditingContext static method setDefaultParentObjectStore (setDefaultParentObjectStore: in Objective-C). For example, Figure 43 shows the nibs for the Rental and Comments windows.

Figure 43. Nibs for the Rental and Comments Windows

Before loading Nib 2, the Rental application should invoke the following code to assign the Rental editing context as the parent object store of the Comments editing context.

In Java:

EODisplayGroup rentalsDisplayGroup;

	// Assume that rentalsDisplayGroup is the display group

	// from Nib 1 and that Nib 1 has already been loaded.

EOEditingContext editingContext;



editingContext = 
displayGroup.dataSource().editingContext();

EOEditingContext.setDefaultParentObjectStore(editingCont
ext);

NSApplication.loadNibNamed("Nib2", this);



// Restore the default behavior

EOEditingContext.setDefaultParentObjectStore(null);

In Objective-C:

EODisplayGroup *rentalsDisplayGroup;

	// Assume that rentalsDisplayGroup is the display group

	// from Nib 1 and that Nib 1 has already been loaded.

EOEditingContext *editingContext;



editingContext = [[displayGroup dataSource] 
editingContext];

[EOEditingContext 
setDefaultParentObjectStore:editingContext];

[NSApplication loadNibNamed:@"Nib2" owner:self];



// Restore the default behavior

[EOEditingContext setDefaultParentObjectStore:nil];

After loading a nib with an editing context substituted as the default parent object store, you should restore the default behavior by setting the default parent EOObjectStore to null (nil in Objective-C). Then when nibs are loaded in the future, their editing contexts are simply connected to the default EOObjectStoreCoordinator.

Table of Contents Next Section