Table of Contents

Previous Section

Figure 31. Typical Configuration of a Graphical User Interface Application

The network of objects is created automatically. For example, all the following procedures create a display group that is automatically associated with an EODatabaseDataSource and its underpinnings:

• Running the EOF Wizard in Project Builder (to create an Application Kit Framework application with a graphical user interface).
• Dragging an entity from a model file into a nib file in Interface Builder.
• Running the WebObjects Application Wizard in Project Builder to create a Main component with database access.
• Dragging an entity from a model file into a component in WebObjects Builder.
• Creating a "Direct-to-Web" application.

The following sections describe how the network of objects is created, starting with a nib or component.

Loading a User Interface

Figure 32. Enterprise Objects Framework Objects in a Nib or Component

Unarchiving an Editing Context

Unarchiving a Database Data Source

1. The EODatabaseDataSource verifies that its underlying EOObjectStoreCoordinator has an EOModelGroup that can service its entity. If you haven't assigned a model group to the coordinator, then the coordinator uses the default model group-the shared EOModelGroup instance returned by the EOModelGroup class method defaultGroup.

   The default model group is created the first time defaultGroup is invoked. Subsequent invocations return the same shared instance. It contains all the models for an application, as well as for any frameworks the application references. In the majority of applications, the default model group is sufficient. However, if your particular application requires different model grouping semantics, you can create your own EOModelGroup instance, add the appropriate models, and assign it to your application's EOObjectStoreCoordinator using the EOModelGroup method setModelGroup (or the EOObjectStoreCoordinator method setModelGroup: in Objective-C).

2. After establishing that its entity can be serviced, the EODatabaseDataSource connects to an EODatabaseContext using the EODatabaseContext static method registeredDatabaseContextForModel (registeredDatabaseContextForModel:editingContext: in Objective-C). This method checks to see if the application's EOObjectStoreCoordinator already has a database context that the data source can use. If it does, it returns that database context. Otherwise it instantiates a new database context, adds it to the coordinator, and returns it.

   When an EODatabaseDataSource connects to an EODatabaseContext, the database context brings in additional supporting objects. A database context can't exist without an EODatabase and an EOAdaptorContext. Similarly, an EODatabase and an EOAdaptorContext can't exist without an EOAdaptor. Thus, as shown in Figure 33, connecting to a database context also connects an EODatabase, an EOAdaptor, and an EOAdaptorContext. Furthermore, if the adaptor bundle associated with the EODatabaseDataSource's model hasn't yet been loaded, it is loaded now.

   

   Figure 33. Connecting an EODatabaseDataSource with an EODatabaseContext

Similarly, all editing contexts in an application share the same EOObjectStoreCoordinator by default.

If you want a different configuration, see the section "Editing Context Configurations". It describes how objects in different nibs can share the same editing context and how to set up nested editing context. The section "Object Store Coordinator Configurations" describes how you can set up multiple EOObjectStoreCoordinators.

Figure 34. Display Groups in the Same Nib Share an Editing Context

Figure 35. Display Groups in Different Nibs Have Separate Editing Contexts

Database Context Rendezvousing

Using the EODatabaseContext static method registeredDatabaseContextForModel (registeredDatabaseContextForModel:editingContext: in Objective-C), a database data source rendezvouses with compatible database contexts whenever possible. A data source is compatible with a database context when the data source's model is compatible with the models in the EOModelGroup of the database context's EODatabase. Two models are compatible when their connection dictionaries are equal as determined by NSDictionary's isEqualToDictionary method (isEqualToDictionary: in Objective-C).

For example, in Figure 36, like-colored gray objects are associated with compatible models-models that have the same connection dictionary. The light gray data source is associated with the light gray database context, and the dark gray data sources are associated with the dark gray database context. The second dark gray data source to be unarchived rendevouses with the first data source's database context.

Figure 36. Data Sources Rendezvous With Compatible EODatabaseContexts

Note that two database data sources can be associated with different models and still share database contexts. So long as the models are compatible, they can be serviced by the same EODatabase and EODatabaseContext.

If you want to prevent an EODatabaseDataSource from rendezvousing on an existing EODatabaseContext, see "Object Store Coordinator Configurations".

Setting Up Channels

Table of Contents Next Section