Method for associating data bearing objects with user interface objects

[0002] This is a continuation of application Ser. No. 08/939,158 filed Sep. 29, 1997, now U.S. Pat. No. 6,154,786, which is a continuation of application Ser. No. 08/353,525 filed Dec. 7, 1994 (now abandoned).

[0003] 1. Field of the Invention

[0004] The present invention relates to the field of object oriented programming languages.

[0005] 2. Background Art

[0006] Object oriented programming languages are programming languages in which program elements are viewed as objects that can pass messages to each other. An object includes its own data and programming code and is internally self-reliant. The programming code of an object includes procedures or methods. The methods of an object are invoked by messages received from another object. Each object is an instance of an object class. The properties of the objects in a class are defined by a class definition. A class definition may utilize a hierarchical class structure in which objects in the class inherit properties of a parent class in addition to properties explicitly defined for the class. This inheritance property allows objects from to be reused from one program to another, facilitating the sharing of programming code between different programs.

[0007] To write an application program in an object oriented programming language, a programmer identifies the real-world objects of a problem, the data and processing requirements of those objects, and the communications needed between the objects, and encapsulates these in class definitions. This process is simplified by taking advantage of the inheritance property of object classes by basing the class definitions to the extent possible on preexisting object classes.

[0008] Objects are assembled in a modular fashion to create applications. Objects communicate with one another by means of messages. In order for meaningful communications to occur, the message sent from a sending object to a receiving object must be a message to which the receiving object can respond. The sending object must therefore know the type of message to which the receiving object will respond. Similarly, if the message is one that invokes a response from the receiving object, the sending object must be prepared to accept the response.

[0009] Although objects are generally internally self-reliant, and can therefore be viewed as modules that can be assembled with other objects into a variety of application programs, the simple assembling of objects does not create a functional program. The objects must also be able to intercommunicate with each other. Although objects represent reusable code, additional code must be written to provide for the required communication between objects. For an object to communicate with a number of different objects, each of which send and receive different messages, the object must be provided with appropriate code for each of the different objects.

[0010] An example is a controlling object that bears data and/or manages a number of data bearing objects and communicates with a number of user interface objects that display data provided by the controlling object to a user and accept input from a user. FIG. 1 shows an example of the interactions between a prior art controller object 100 managing data bearing objects 105ato 105fand a graphical user interface 110. Graphical user interface 110 includes three kinds of user interface objects: a table object 120, two text field objects 130 and 140, respectively, and two check box objects 150 and 160, respectively. Each of these three kinds of user interface objects operates differently and responds to and generates different messages. Controller 100 therefore contains separate interface code for interfacing with each kind of object. Accordingly, controller 100 contains table object interface code 170, text field object interface code 180, and check box object interface code 190.

[0011] Certain prior art object oriented programming environments provide user interfaces with a predefined structure. These predefined structures do not allow developers the freedom to easily assemble custom user interfaces.

[0012] The present invention comprises a method for allowing a controlling object to interface with any number of user interface objects without requiring separate interface code for each user interface object and without restricting the user interface to certain predetermined designs. The present method provides objects called association objects that are interposed between a controlling object and each user interface object. Each kind of user interface object has a corresponding association object. The association object for a particular kind of user interface object contains code that allows the association object to interact with the specific kind of user interface object with which it is associated. Each association object also presents a standard interface to a controlling object, regardless of the kind of user interface object with which the association object is associated. The association object takes care of any conversion or translation that must be performed to convert a data value sent by the controlling object into an appropriate value that can be displayed by the user interface object. Accordingly, instead of requiring different interface code for each kind of user interface object used, a controlling object requires only a single block of interface code for communicating with all association objects, which in turn provide the user interface specific code needed for each kind of user interface object.

[0013] FIG. 1 is a diagram of a controller object and user interface objects of the prior art.

[0014] FIG. 2 is a diagram of a controller object and user interface objects in one embodiment of the present invention.

[0015] FIG. 3 is a diagram of the architecture of an Enterprise Objects Framework application.

[0016] FIG. 4 is a diagram showing the relationship between data contained in a database and data contained in dictionary and enterprise objects in one embodiment of the present invention.

[0017] FIG. 5 is a flow chart for one embodiment of the present invention.

[0018] FIG. 6A is a flow diagram illustrating “takeValuesFromDictionary”.

[0019] FIG. 6B is a flow diagram illustrating “findMethod”.

[0020] FIG. 6C is a flow diagram illustrating “findInstance”.

[0021] FIG. 7A is a flow diagram illustrating “valuesForKeys”.

[0022] FIG. 7B is a flow diagram illustrating “returnMethod”.

[0023] FIG. 7C is a flow diagram illustrating “returnInstance”.

[0024] In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent to one skilled in the art, however, that the present invention may be practiced without these specific details. In other instances, well-known features have not been described in detail in order not to unnecessarily obscure the present invention.

[0025] FIG. 2 is a block diagram showing the relationship between a controlling object and user interface objects in one embodiment of the present invention. FIG. 2 shows a controller object 100 that manages a number of data bearing objects 105ato 105fand a user interface 110 including a table object 205, two text field objects 130 and 140, respectively, and two check box objects 150 and 160 respectively. Controller 100 passes data between data bearing objects 105ato 105fand the various user interface objects 120, 130, 140, 150 and 160. However, instead of sending and receiving messages directly to and from the user interface objects as in the prior art system of FIG. 1, in the embodiment of the present invention shown in FIG. 2, controller 100 communicates indirectly with the user interface objects via “association” objects 210a, 210b, 210c, 220a, 220b, 230aand 230bthat are interposed between controller 100 and each of user interface objects 205a, 205b, 205c, 130, 140, 150 and 160, respectively. Controller 100 sends and receives messages to and from the association objects, while the association objects send and receive messages to and from the user interface objects as well as to and from controller 100. The association objects present a consistent interface to controller 100. Accordingly, instead of having blocks of interface code for each of the three kinds of user interface objects contained in user interface 110 (i.e. table objects, text field objects, and check box objects), controller 100 needs only a single block of interface code with which it can communicate with any association object. The association objects in turn take care of any conversion or translation required between messages sent and received by controller 100 and messages sent and received by the various user interface objects.

[0026] In the embodiment of the invention shown in FIG. 2, a separate association object is utilized for each user interface object, even if there are several user interface objects of the same kind. Thus, in the embodiment of FIG. 2, separate text field association objects 220aand 220bare used for each of text field objects 130 and 140, respectively. In the same manner, separate check box association objects 230aand 230bare used for each of check box objects 150 and 160, respectively, and separate table column association objects 210a, 210band 210care used for each column of table 205, which in this embodiment comprises table column objects 205a, 205band 205c, respectively. In other embodiments, table 205 may comprise a single object and be associated with a single association.

[0027] Association objects are objects provided by the present invention that can be utilized by a programmer to tie a controlling object to a variety of different kinds of user interface objects, without requiring the programmer to provide the controlling object with the code necessary to communicate with each type of user interface object. The controlling object need only be provided with the means to send and respond to standard messages. The association objects in turn take care of the message sending and receiving requirements specific to each kind of user interface object. The object oriented programming environment used with the embodiment of FIG. 2 is particularly suited for the development of data base application programs. However, the method of the present invention can also be used for non-data base applications.

[0028] The association objects of the present invention are useful particularly in a programming environment that provides a selection of user interface objects to a programmer. The present invention adds a pre-defined association for each user interface object provided by the programming environment. An application programmer wishing to display data from a controlling object can easily create an appropriate user interface by selecting the desired user interface object and linking it with the controlling object using the appropriate association object for the user interface object selected. A programmer may also develop custom user interface objects and corresponding association objects.

[0029] The purpose of a user interface is to display data output to a user and to accept data input from a user. Although the specific mechanics of how data is displayed on a user interface or how it is received from a user varies depending upon the specific type of user interface object used, the basic underlying process is the same: a user interface object receives data from a controlling object and displays it, in some manner, on the user interface; if a change is made by the user on the user interface, that change is transmitted to the controlling object. The present invention allows the controlling object to deal with these basic underlying processes, while isolating the controlling object from any more complex control requirements of particular user interface objects.

[0030] One embodiment of the present invention is used in “Enterprise Objects Framework (™)”, a set of tools and resources for the NEXTSTEP (™) object oriented programming environment from NeXT Computer, Inc. Enterprise Objects Framework provides tools that enable program developers to design database applications that work with relational databases, that are easy to build and maintain, that communicate with other applications, and that utilize standard interface features. Enterprise Objects Framework is described in detail in Enterprise Objects Framework Developer's Guide(NeXT Computer, Inc., 1994) and Enterprise Objects Framework Reference(NeXT Computer, Inc., 1994), both of which are incorporated herein by reference.

[0031] The architecture and data flow of an Enterprise Objects Framework application is shown in FIG. 3. In the application shown in FIG. 3, data flows from a relational database 300 to a user interface 360, and vice versa, via a number of intervening modules and levels.

[0032] The flow of data from the relational database 300 to user interface 360 proceeds as follows. Data in the form of rows of data from relational database 300 are retrieved from relational database 300 to an adaptor level 310, using well-known relational database access techniques. At adaptor level 310, the raw data received from relational database 300 is packaged into “dictionary objects.” Dictionary objects contain key-value pairs: each key typically represents the name of a database column, and the key's value corresponds to the data for the column of the particular row that was read from relational database 300. The key-value coding protocol used in Enterprise Objects Framework is described below in the section entitled “Key-Value Coding Protocol”. This key-value coding protocol is also described in co-pending U.S. patent application Ser. No. 08/353,524 for “Dynamic Object Communication Protocol” filed on Dec. 7, 1994, assigned to the assignee of the present invention, and incorporated herein by reference. As shown in FIG. 3, data in the form of these dictionary objects is passed from adaptor level 310 to database level 320.

[0033] Database level 320 creates “enterprise objects” from the dictionary objects. Enterprise objects are like other objects used in object oriented programming languages in that they couple data with methods for operating on that data. However, an enterprise object has certain characteristics that distinguish it from other object classes. An enterprise object has properties that map to stored data, and an instance of an enterprise object typically corresponds to a single row or record in a database. Further, an enterprise object knows how to interact with other parts of the Enterprise Object Framework to give and receive values for its properties. The ingredients that make up an enterprise object are its class definition and the data values for the row or record to which it corresponds. The mechanism that enables an enterprise object to exchange its values with other objects is the Key Value Coding protocol referred to above and described below in the section entitled “Key-Value Coding Protocol”. The Key Value protocol also allows an object to set its values at runtime from a dictionary, as explained below.

[0034] When an object is to be loaded with values from a dictionary, the methods and instance variables of the object are examined to determine if there is a match between keys in the dictionary and the object. This is accomplished by searching for the method “set (property)” where property is the column name or key in the dictionary. For example, with property named “lastName”, the system looks for a method of the form “setLastName”. If there is a match, the value of the property “lastName” can be loaded into the object using the setLastName method.

[0035] If no methods produce a match, the system looks for an instance variable whose name is the same as the property's and sets is value directly.

[0036] When a dictionary is to be loaded with values from an object, the properties of the dictionary are provided as an array. For each property, the methods of the object are examined to determine if they are of the form “property”. If there is a match, the object's value for that method is returned to the dictionary. If there is no match, the instances of the object are examined. If an instance is found that matches the property, the value is returned to the dictionary.

[0037] takeValuesFromDictionary

[0038] The method for setting values in an object is implemented by “takeValuesFromDictionary”. This method is implemented on the root object of the environment so that, in a class hierarchy system, every object inherits the method. In one embodiment, the default implementations of the key-value coding methods use the class definition as follows:

[0039] 1. The key-value coding method looks for an accessor method based on the property name. For example, with a property named lastname, take ValuesFromDictionary: looks for a method of the form setLastName: (note that the first letter of the property name is made uppercase).

[0040] 2. If the key-value coding method doesn't find an accessor method, it looks for an instance variable whose name is the same as the property's and sets or retrieves its value directly. In setting an instance variable, takeValuesFromDictionary: retains the new value and releases the old one.

[0041] The takeValuesFromDictionary method may be implemented as described in the pseudo code provided in the section entitled “Pseudocode”. The operation of takeValuesFromDictionary is illustrated in the flow diagrams of FIGS. 6A, 6B, and 6C.

[0042] takeValuesFromDictionary Flow

[0043] Referring first to FIG. 6A takeValuesFromDictionary is illustrated. At decision block 602, the argument “All key-value pairs in dictionary processed?” is made. This step checks to see if the object has been examined for all dictionary pairs. If the argument at decision block 602 is true, the system ends at step 612. That means that all dictionary pairs have been processed for the object, and thus the method is completed. If the argument at decision block 602 is false, not all pairs have been processed. At step 604 the class description for the object is obtained and examined. At step 606, “findMethod” is executed to determine if the object has a set method with a name that matches a property of the key-value pair. This step is illustrated in more detail in FIG. 6B.

[0044] After findMethod has been executed at step 606, the system proceeds to decision block 608. At decision block 608, the argument “method found?” is made. This step is to determine whether there has been a match between the methods of the object and the property of the key-value pair. If the argument at decision block 608 is true, a match has been found and the data can be loaded into the object. The routine of FIG. 6A ends at step 612. If the argument at decision block 608 is false, no methods match the property of the key-value pair and the system must then check the instances of the object. This is accomplished by invoking “findInstance” at step 610. This step is illustrated in more detail in FIG. 6C. After findInstance has been executed, the system ends at step 612.

[0045] findMethod Flow

[0046] Step 606 of FIG. 6A, “findMethod” is illustrated in more detail in FIG. 6B. The process “findMethod” is used to examine the methods of the object being examined to determine if its methods match the properties of the key-value pairs being processed. At step 622, the method to be searched for is defined as being of the type “set” plus the property of the key being processed (e.g. if the property of the key-value pair is “lastName”, then the system looks for “setLastName”). At step 624, the class description is examined for the method that is being searched. At decision block 626, the argument “method found?” is made. This is to determine if the object contains the method that is being searched. If the argument is false, findMethod ends at step 634 and returns to decision block 626 of FIG. 6A.

[0047] If the argument at decision block 626 is true, a match has been found. The system at 628 determines the argument type for the method. At step 630, the value of the key-value pair is converted to the argument type if necessary. At step 632, the method with the value as argument is called to load the data value into the object. At step 634, findMethod ends and returns to takeValuesFromDictionary of FIG. 6A.

[0048] findInstance Flow

[0049] Step 610 of FIG. 6A, “findInstance”, is illustrated in FIG. 6C. In the preferred embodiment of the present invention, the methods of an object are examined first when attempting to load data. If no suitable methods are found, the instance variables are examined using “findInstance”. At step 642, the class description of the object is examined to determine if there is an instance equal to the key property of the key-value pair being processed. At decision block 644, the argument “instance found?” is made. If the argument is false, that is if no instances match the property, the findInstance process ends at step 644 and returns to step 612 of FIG. 6A.

[0050] If the argument at decision block 644 is true, a match between and instance variable and the key-value property has been found. The system then at step 646 determines the instance type. At step 648, the storage offset of the instance in the object is determined. At step 650, the value of the key-value pair being examined is converted to the object's instance type. At step 652, the value from the key-value pair is assigned to the instance in the object using the previously determined instance offset. At step 654, findInstance ends and returns to step 612 of FIG. 6A.

[0051] valuesForKeys

[0052] The method for loading a dictionary with values from an object is “valuesForKeys”. The class definitions for valuesForKeys is as described above for “takeValuesForDictionary”. The valuesForKeys method may be implemented as described in the pseudo code (see section entitled “Pseudocode” below). The operation of valuesForKeys is illustrated in the flow diagrams of FIGS. 7A, 7B, and 7C.

[0053] valuesForKeys Flow

[0054] Referring first to FIG. 7A, valuesForKeys is illustrated . When valuesForKeys is invoked, it is to take data from an object and load it into a data destination (e.g. a relational database). The properties of the keys of the key-value dictionary of the data destination are put into a key array. At decision block 720, the argument “All keys in key array processed?” is made. If the argument is true, all array entries have been processed and the method is over, the process ends at step 714. If the argument is false, the next key in the key array is processed. At step 704, the system gets the class description for the object. At step 706, “returMethod” is executed to determine if the object has any methods (e.g. setValue, getValue, etc.) that match the key property. This step is illustrated in more detail in FIG. 7B.

[0055] After returnMethod has been executed at step 706, the system returns to decision block 708. At decision block 708, the argument “method found?” is made. This step is to determine whether there was a match between any of the methods of the object and the key property. If the argument at decision block 708 is true, a match has been found and the data can be loaded into the data destination. The process then ends at step 714. If the argument at decision block 708 is false, no methods match the key property. The system then checks the instance variables for matches. This is accomplished by invoking “returnInstance” at step 710. This step is illustrated in more detail in FIG. 7C. After returnInstance has been executed, the process stores the key and returned value as a key-value pair in the key-value dictionary. At step 714, valuesForKeys ends.

[0056] returnMethod Flow

[0057] Step 706 of FIG. 7A, “returnMethod”, is illustrated in FIG. 7B. The process “returnMethod” is used to examine the methods of the object to determine if any; of its methods match the property of the key property array value being processed. At step 722, the method to be searched for is made defined as one having the current key property. At step 724, the class description is examined for the defined method. At decision block 726, the argument “method found?” is made. If the argument is false, there is no match, returnMethod ends at step 734 and returns to valuesForKeys of FIG. 7A.

[0058] If the argument is true, at step 728, a match has been found. At step 728, the value type of the method is determined. At step 730, the method is called and returns the result as value. At step 732, the process converts the value to value type, if necessary, and the value can be loaded into the data destination. The process returnMethod ends at step 734.

[0059] returnInstance Flow

[0060] Step 710 of FIG. 7A, “returnInstance” is illustrated in FIG. 7C. In the preferred embodiment of the present invention, this process is invoked only when no matching methods have been found for a key property being processed. At step 742, the class description is examined to determine if there is an instance variable that matches the key property. At decision block 744, the argument “instance found?” is made. If the argument is false, no matches have been found, the returnInstance process ends at step 752 and returns to valuesForKeys of FIG. 6A.

[0061] If the argument at decision block 744 is true, there is a match of an instance variable and the key property. At step 746, the type of the instance variable is determined. At 748, the storage offset of the instance variable in the object is determined. At step 750, the value of the instance is converted to instance type and can be loaded into key-value pair of the dictionary of the data destination. At step 752, returnInstance ends and returns to valuesForKeys of FIG. 7A.

[0062] Returning to FIG. 3, the enterprise objects created at database level 320 are passed from database level 320 to data source 330. Data source 330 is an object that has the ability to fetch, insert, update and delete enterprise objects. Changes made by data source 330 to an enterprise object are passed down via database level 320 and adaptor level 310 to relational database 300 so that a corresponding change is made to the database for a change made to an enterprise object.

[0063] Data source 330 supplies enterprise objects created at database level 320 to controller 340. As shown in FIG. 3, controller 340 transports data in the form of values from the enterprise objects to user interface 360 via association objects 350. Controller 340 coordinates the values displayed in the user interface with the corresponding enterprise object values. When enterprise objects are modified, controller 340 tells data source 330, which is responsible for propagating changes to relational database 300. A description of the controller object class provided by Enterprise Objects Framework is set forth below in the section entitled “Controller Object Class”.

[0064] Movement of data in the architecture shown in FIG. 3 is bi-directional. Changes made by a user to data values displayed on user interface 360 propagate to relational database 300 in the opposite direction as data from database 300 propagates to user interface 360.

[0065] As mentioned above, the mechanism by which data moves through an Enterprise Object Framework application is a key-value coding informal protocol. Regardless of their characteristics, objects that conform to the key-value coding protocol (such as enterprise objects) have a common characteristic: their data is accessed by other objects in the form of key-value pairs. Key-value coding methods enable an object to receive values for its keys and to give out its keys' values to other objects.

[0066] By using key-value coding, different types of objects can pass their values to each other, thereby transporting data through the different layers shown in FIG. 3. FIG. 4 shows how the properties in an enterprise object 420 correspond to the key-value pairs in a dictionary 410, and how both in turn correspond to a row in a relational database 400. Enterprise object properties and dictionary keys (such as firstName and lastName shown in FIG. 4) map to columns in the database; the value for each key (for example “Lesly” and “Oswald”, respectively) matches the column's value for the corresponding row.

[0067] User interface 360 of FIG. 3 typically contains a number of user interface objects such as pop-up lists, forms, text fields, and tables. These user interface objects display the values of keys of enterprise objects, and, if the values are edited in the user interface, communicate the changes back to the enterprise objects.

[0068] The interface between user interface objects and related enterprise objects is provided by controller object 340 and association objects 350 of FIG. 3, which together may be viewed as an interface layer between enterprise objects and user interface objects.

[0069] The primary actor in the interface layer is controller 340. Controller 340 uses association objects to mediate between enterprise objects and user interface 360. Each association object links a single user interface object to a class property name (key) in an enterprise object or objects managed by the controller. The property (key) value is displayed in the user interface object with which the association object is linked. Enterprise Objects Framework provides a number of pre-defined association objects and associated user interface objects to the developer. The section entitled “Association Objects” (below) contains descriptions of association objects provided by Enterprise Objects Framework. Specific association objects provided by Enterprise Objects Framework include EOAssociation (an abstract association object class) and the subclasses EOActionCellAssociation, EOColumnAssociation; EOControlAssociation; EOImageAssociation; EOMatrixAssociation, EOPopUpAssociation; EOQualifiedAssociation; and EOTextAssociation.

[0070] As described above, an association object ties a single user interface object (such as a text field) to a value corresponding to a key in an enterprise object or objects managed by the controller object. For example, a text field may display the value “Jun-19-1992” for the key “hireDate” of enterprise object 420 of FIG. 4. An association object is provided with an appropriate key to enable it to obtain data from a data bearing object using a key-value coding protocol. By means of association objects and their keys and the key-value coding system, a controller can set data from data bearing objects to user interface objects and retrieve data from user interface objects into data bearing objects. The user interface objects, association objects, and keys can be assembled without data, and be archived for later use with an application program. By using the key-value coding protocol, these objects can be assembled and configured ahead of time and made to execute at run time with no compilation.

[0071] One of the functions performed by association objects, if needed, is to convert values extracted by the controller from an enterprise object and passed to an association object to a type that can be displayed by the corresponding user interface object. In a similar manner, a data source converts edited values returned to the controller from an association object to an appropriate value class that can be applied by the data source to the corresponding enterprise object.

[0072] A controller works closely with its association objects to ensure that values displayed in the user interface remain synchronized with the corresponding enterprise object values. When an enterprise object value changes, the controller tells its association objects. Conversely, when an association object is notified of a change in a displayed value by its user interface object, the association object informs its controller of the change that occurred.

[0073] FIG. 5 shows the sequence of steps that occur when the value displayed by a user interface object has changed. The sequence starts when a user changes the value of a displayed user interface object at block 500. For example, a user may change the hire date of “Jun-19-1992” displayed in a text field object for enterprise object 420 of FIG. 4 to a new date of “Jun-19-1991” by typing the new date in the text field object displayed on the user interface.

[0074] In response to this change, at block 510 of FIG. 5, the user interface object sends its association object (in this embodiment there is a one-to-one correspondence between user interface objects and association objects) a message that this user initiated change has occurred. The association object, in turn, at block 520, notifies its controller of the change by sending the controller a “associationDidEdit” message. An “associationDidEdit” message informs the controller that a change has occurred, but does not include the new value. To obtain the new value, the controller sends the notifying association object a “value” message at block 530, upon which the association object returns the new value at block 535.

[0075] After receiving the new value, the controller sends its data source a “coerceValue:forKey;” message at block 540. This message causes the data source to convert the new value received from the association object to a value class type that can be used by the corresponding enterprise object. The controller then delivers the new, converted value to the enterprise object by means of a “takeValuesFromDictionary:” message at block 550. “takeValuesFromDictionary” is a standard message that is part of the key-value coding protocol used to transfer data between objects in the Enterprise Objects Framework.

[0076] Next, the controller sends “updateObject:” and “saveobjects” messages to its data source at block 560. In response to these messages, the data source causes the data in the database to be updated and stored to reflect the new value.

[0077] Although the above sequence of steps has been described as taking place in without buffering, buffering techniques that are well known in the art can be used at various steps along the sequence. For example, changes made in the user interface objects can be buffered before being sent to update the enterprise objects, or changes to the enterprise objects can be made without buffering while the sending of the changes to the data source is buffered.

[0078] Since each user interface object has a corresponding association object, and since a user interface typically has a number of user interface objects, a controller will typically be associated with a number of association objects. Further, a number of different user interface objects may display a value for the same key of an enterprise object. As a result, if a value displayed by one user interface object is changed by a user, that change may be reflected in other user interface objects. Accordingly, after the value in an enterprise object has been changed in response to a new value entered by the user, the controller sends all of its association objects “contentsDidChange” messages at block 570. In addition, when the change in value also causes the selected enterprise object to change (a “selected” enterprise object is the current object for which values are displayed in the user interface, or, in the case where a user interface object displays values for multiple enterprise objects simultaneously, such as a table, the selected enterprise object is the object whose values are highlighted), the controller also sends all of its association objects a “selectionDidChange” message at block 580. This enables each association object to display values for the currently selected enterprise object, or highlight the values for the selected enterprise object if the user interface object associated with the association object displays values for multiple enterprise objects.

[0079] A “contentsDidChange” message received by an association object constitutes a signal to the association object that the value displayed by its user interface object may have changed. To determine whether the change that occurred affects the value that an association object is displaying in its user interface object, at block 585, each association object sends the controller a “valuesForKeys” message to obtain the current value for the key that is displayed in the association object's user interface object. “valuesForKeys”, like “takeValuesFromDictionary”, is a standard message that is part of the key-value coding protocol used to transfer data between objects in the Enterprise Objects Framework. When an association object receives the current value for its user interface object, it compares the current value with the last value that it received (which ordinarily would also be the value being displayed by its user interface object) at block 590. If the current value is different from the last value, the association object sends a message to its user interface object to update the displayed value to the new value at block 595.

[0080] From the point of view of the controller, all association objects look the same: the controller communicates with all association objects using the same set of standard messages. The process shown in FIG. 5, particularly from block 520 onward, thus applies in general to any change in value made to any user interface object. The way in which a user interface object interacts with its association object, and the specific messages that are used for communications between an association object and its user interface object, however, will vary depending upon the characteristics specific to a particular user interface object. Accordingly, the particular manner in which the steps shown in blocks 500 and 510 are performed may vary from association object to association object.

[0081] In addition to informing its association objects when its enterprise objects or currently selected enterprise object have changed, a controller in Enterprise Objects Framework uses a “endEditing” method to order its association objects to finish editing. Before a controller can perform certain operations (such as fetching, inserting a new enterprise object, or setting an undo mark) it must collect any new edits from its association objects. When the controller sends “endEditing” messages to its association objects, they finish editing, relinquish first responder status, and notify the controller of any changes with “associationDidEdit:”. The protocol used by a controller to send notification messages to its association objects is described below in the section entitled “Notification Protocol”.

[0082] In addition to providing a number of pre-defined user interface objects and association objects, Enterprise Objects Framework allows a developer to create custom user interface objects and associated custom association objects. The “EOAssociation” object described below in the section entitled “Association Objects” can be used by a developer as a basis for defining a custom association object.

[0083] Thus a method for associating controlling and data bearing objects with user interface objects has been presented. Although the present invention has been described with respect to certain example embodiments, it will be apparent to those skilled in the art that the present invention is not limited to these specific embodiments. For example, instead of communicating with data bearing objects via a controller object, the association objects of the present invention may communicate directly with data bearing objects. Instead of using a separate association object for each user interface object, an association object may be associated with more than one user interface object. The specific messages sent and received by association objects and data bearing and data controlling objects can vary from the specific messages described herein. The specific steps and sequences of steps described herein may be configured by a user and may vary from one embodiment to another. Other embodiments incorporating the inventive features of the present invention will be apparent to those skilled in the art.

[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]