DE69522713T2

DE69522713T2 - Verfahren zum assoziieren von datentragenden objekten mit objekten der benutzerschnittstelle

Info

Publication number: DE69522713T2
Application number: DE69522713T
Authority: DE
Inventors: Jack Greenfield; Linus Upson; Daniel Willhite; Richard Williamson
Original assignee: Next Software Inc
Current assignee: Next Software Inc
Priority date: 1994-12-07
Filing date: 1995-12-07
Publication date: 2002-07-04
Anticipated expiration: 2015-12-08
Also published as: DE69522713D1; WO1996018147A1; US6513072B1; EP0803093B1; US6154786A; CA2207331A1; CA2207331C; AU4465996A; EP0803093A4; EP0803093A1

Description

HINTERGRUND DER ERFINDUNG

1. GEBIET DER ERFINDUNG

Die vorliegende Erfindung betrifft das Gebiet objektorientierter Programmiersprachen.

2. TECHNISCHER HINTERGRUND

Objektorientierte Programmiersprachen sind Programmiersprachen, bei welchen Programmelemente als Objekte gesehen werden, welche sich gegenseitig Nachrichten zuleiten können. Ein Objekt weist seinen eigenen Daten- und Programmiercode auf und ist intern selbständig. Der Programmiercode eines Objekts weist Prozeduren oder Verfahren auf. Die Verfahren eines Objekts werden durch Nachrichten, welche von einem anderen Objekt empfangen werden, aufgerufen. Jedes Objekt ist eine Instanz einer Objektklasse. Die Eigenschaften eines Objekts in einer Klasse sind durch eine Klassendefinition definiert. Eine Klassendefinition kann eine hierarchische Klassenstruktur verwenden, bei welcher Objekte in der Klasse Eigenschaften einer Stammklasse erben und zwar zusätzlich zu Eigenschaften, welche ausdrücklich für die Klasse definiert sind. Diese Vererbungseigenschaft ermöglicht Objekten davon von einem Programm zu einem anderen mehrfach aufgerufen zu werden, wodurch das gemeinsame Nutzen von Programmiercode zwischen verschiedenen Programmen erleichtert wird.
Um ein Anwendungsprogramm in einer objektorientierten Programmiersprache zu schreiben, identifiziert ein Programmierer die realen Objekte eines Problems, die Daten- und Verarbeitungsanforderungen jener Objekte und die zwischen den Objekten benötigte Kommunikation und verkapselt dies in Klassendefinitionen. Dieser Prozeß wird vereinfacht, indem aus der Vererbungseigenschaft von Objektklassen Vorteil gezogen wird, indem die Klassendefinitionen in dem möglichen Umfang auf vorexistierende Objektklassen basiert werden.
Objekte werden in einer modularen Gestalt assembliert, um Anwendungen zu erzeugen. Objekte kommunizieren mittels Nachrichten miteinander. Um sinnvolle Kommunikation zu erreichen, muß die Nachricht, welche von einem Sendeobjekt zu einem Empfangsobjekt gesendet wird, eine Nachricht sein, auf welche das Empfangsobjekt antworten kann. Das Sendeobjekt muß dafür den Nachrichtentyp kennen, auf welchen das Empfangsobjekt antworten wird. Gleichermaßen muß das Sendeobjekt, wenn die Nachricht eine ist, welche eine Antwort von dem Empfangsobjekt aufruft, vorbereitet sein, um die Antwort zu akzeptieren.
Obwohl Objekte im Allgemeinen intern selbständig sind und daher als Module gesehen werden können, welche mit anderen Objekten in eine Vielfalt von Anwendungsprogrammen assembliert werden können, erzeugt das einfache Assemblieren von Objekten kein funktionelles Programm. Die Objekte müssen auch gegenseitig miteinander kommunizieren können. Obwohl Objekte mehrfach aufrufbaren Code darstellen, muß zusätzlicher Code geschrieben werden, um für die erforderliche Kommunikation zwischen Objekten zu sorgen. Denn damit ein Objekt mit einer Anzahl von verschiedenen Objekten kommuniziert, wobei jedes von diesen verschiedene Nachrichten sendet und empfängt, muß das Objekt mit geeignetem Code für jedes der verschiedenen Objekte ausgestattet sein.
Ein Beispiel ist ein Steuerungsobjekt, welches Daten trägt und/oder eine Anzahl von datentragenden Objekten verwaltet und mit einer Anzahl von Benutzerschnittstellenobjekten kommuniziert, welche Daten anzeigen, welche durch das Steuerungsobjekt an einen Benutzer geliefert werden, und Eingaben von einem Benutzer akzeptieren. Fig. 1 zeigt ein Beispiel der Wechselwirkungen zwischen einem Steuerungsobjekt 100 aus dem Stand der Technik, welches datentragende Objekte 105a bis 105f verwaltet, und einer graphischen Benutzerschnittstelle 110. Die graphische Benutzerschnittstelle 110 weist drei Arten von Benutzerschnittstellenobjekten auf: ein Tabellenobjekt 120, zwei Textfeldobjekte 130 bzw. 140 und zwei Ankreuzboxobjekte 150 bzw. 160. Jede dieser drei Arten von Benutzerschnittstellenobjekten arbeitet verschiedenartig und antwortet auf und erzeugt verschiedene Nachrichten. Die Steuerung 100 weist dafür gesonderten Schnittenstellencode auf, um Schnittstellen für jede Art von Objekt bereitzustellen. Entsprechend weist die Steuerung 100 Tabellenobjekt- Schnittstellencode 170, Textfeldobjekt-Schnittstellencode 180 und Ankreuzboxobjekt-Schnittstellencode 190 auf.
Bestimmte objektorientierte Programmierumgebungen aus dem Stand der Technik stellen Benutzerschnittstellen mit einer vordefinierten Struktur bereit. Diese vordefinierten Strukturen geben Entwicklern nicht die Freiheit, auf einfache Weise kundenspezifische Benutzerschnittstellen zu assemblieren.
Darüber hinaus beschreibt das Dokument "ENTERPRISE OBJECTS FRAMEWORK: BUILDING REUSABLE BUSINESS OBJECTS" NEXT COMPUTER PUBLICATION, Juli 1994, REDWOOD CITY, CA, USA, Seiten 1-13 eine Unternehmensobjekts-Grundstruktur, bei welcher Assoziierungsobjekte zwischen einem Steuerungsobjekt und jedem Benutzerschnittstellenobjekt zwischengeschaltet sind. Alle Assoziierungsobjekte weisen eine gemeinsame Nachrichtenschnittstelle bezüglich des Steuerungsobjektes auf, wobei aber jedes Assoziierungsobjekt eine spezifische Nachrichtenschnittstelle bezüglich eines zugehörigen Benutzerschnittstellenobjekts aufweist. Somit muß das Steuerungsobjekt nicht konfiguriert werden, um alle die spezifischen Nachrichtenformate von allen der Benutzerschittstellenobjekte zu unterstützen.
Aus der US-A-5 327 529 ist ein Prozeß zum Entwerfen von Benutzerschnittstellen für Anwendungsprogramme bekannt. Eine generische Benutzerschnittstelle wird definiert, sowie eine oder mehrere spezifische Benutzerschnittstellenimplementierungen. Die Anwendung wird hinsichtlich der generischen Benutzerschnittstelle entworfen. Ein Interpretierer wird für jede spezifische Benutzerschnittstellenimplementierung bereitgestellt, so daß die spezifische Benutzerschnittstelle für die Anwendung nicht bis zur Ausführungszeit bestimmt werden muß.
Schließlich stellt die US-A-5 276 816 ein System und ein Verfahren zum Interpretieren von Nachrichten bereit, welche von einer Ein-/Ausgabevorrichtung zu einem Anwendungsobjekt gesendet werden, so daß die Interpretation der Nachrichten konsistent sein wird und zwar ungeachtet der Ein- /Ausgabevorrichtung, welche zum Erzeugen der Nachricht verwendet wird. Es werden auch Mittel bereitgestellt, um eine Objekt-Objekt-Wechselwirkung festzustellen und resultierende Nachrichten zu erzeugen.
In allen der obigen drei Referenzen ist jedoch ein beträchtlicher Mangel an Flexibilität vorhanden und zwar auf Grund der spezifischen Datenwerttypen in verschiedenen Benutzerschnittstellenobjekten, welche anzuzeigen sind.

ZUSAMMENFASSUNG DER VORLIEGENDEN ERFINDUNG

Ein Ziel der vorliegenden Erfindung ist, die obigen Beschränkungen zu vermindern und eine Generalisierung der Implementierung des Steuerungsobjekts und der Benutzerschnittstellenobjekte durch geeignete Konvertierung der Datenwerttypen zu ermöglichen.
Genauer gesagt stellt die vorliegende Erfindung ein Assoziierungsverfahren, wie im beigefügten Anspruch 1 definiert, und ein Verfahren zum Anzeigen von Daten, wie in Anspruch 12 definiert, bereit.
Entsprechend erfordert ein Steuerungsobjekt, anstatt verschiedenen Schnittstellencode für jede Art von benutztem Benutzerschnittstellenobjekt zu erfordern, nur einen einzigen Block an Schnittstellencode, um mit allen Assoziierungsobjekten zu kommunizieren, welche umgekehrt den benutzerschnittstellenspezifischen Code bereitstellen, welcher für jede Art von Benutzerschnittstellenobjekt benötigt wird.
Bevorzugte, aber wahlweise Ausgestaltungen dieser Verfahren sind in den jeweiligen abhängigen Ansprüchen angeführt.

KURZE BESCHREIBUNG DER ZEICHNUNG

Fig. 1 ist ein Diagramm eines Steuerungsobjektes und von Benutzerschnittstellenobjekten aus dem Stand der Technik.
Fig. 2 ist ein Diagramm eines Steuerungsobjektes und von Benutzerschnittstellenobjekten in einem Ausführungsbeispiel der vorliegenden Erfindung.
Fig. 3 ist ein Diagramm der Architektur einer Enterprise Objects Framework (Unternehmensobjekte- Grundstruktur)-Anwendung.
Fig. 4 ist ein Diagramm, welches die Beziehung zwischen in einer Datenbank enthaltenen Daten und im Verzeichnis enthaltenen Daten und Unternehmensobjekten in einem Ausführungsbeispiel der vorliegenden Erfindung zeigt.
Fig. 5 ist ein Flußdiagramm für ein Ausführungsbeispiel der vorliegenden Erfindung.
Fig. 6A ist ein Flußdiagramm, welches "takeValuesFromDictionary" (nehmenWertevon Verzeichnis) darstellt.
Fig. 6B ist ein Flußdiagramm, welches "findMethod" (findenverfahren) darstellt.
Fig. 6C ist ein Flußdiagramm, welches "findInstance" (findenlnstanz) darstellt.
Fig. 7A ist ein Flußdiagramm, welches "valuesForKeys" (WerteFürSchlüssel) darstellt.
Fig. 7B ist ein Flußdiagramm, welches "returnMethod" (zurückgebenVerfahren) darstellt.
Fig. 7C ist ein Flußdiagramm, welches "returnInstance" (zurückgebenInstanz) darstellt.

DETAILLIERTE BESCHREIBUNG DER ERFINDUNG

In der folgenden Beschreibung werden zahlreiche spezifische Details bekannt gemacht, um für ein völliges Verständnis der vorliegenden Erfindung zu sorgen. Es wird jedoch für einen Fachmann ersichtlich sein, daß die vorliegende Erfindung ohne diese spezifischen Details ausgeführt werden kann. In anderen Fällen sind weithin bekannte Merkmale nicht im Detail beschrieben worden, um die vorliegende Erfindung nicht unnötigerweise unverständlich zu machen.
Fig. 2 ist ein Blockdiagramm, welches die Beziehung zwischen einem Steuerungsobjekt und Benutzerschnittstellenobjekten in einem Ausführungsbeispiel der vorliegenden Erfindung zeigt. Fig. 2 zeigt ein Steuerungsobjekt 100, welches eine Anzahl von datentragenden Objekten 105a bis 105f verwaltet, und eine. Benutzerschnittstelle 110, welche ein Tabellenobjekt 120, zwei Textfeldobjekte 130 bzw. 140 und zwei Ankreuzboxobjekte 150 bzw. 160 aufweist. Die Steuerung 100 leitet Daten zwischen datentragenden Objekten 105a bis 105f und den verschiedenen Benutzerschnittstellenobjekten 120, 130, 140, 150 und 160 weiter. Anstatt jedoch Nachrichten direkt an die Benutzerschnittstellenobjekte zu senden und von diesen zu empfangen, wie in dem Stand der-Technik-System von Fig. 1, kommuniziert die Steuerung 100 in dem in Fig. 2 gezeigten Ausführungsbeispiel der vorliegenden Erfindung indirekt mit den Benutzerschnittstellenobjekten über "Assoziierungs"-Objekte 210a, 210b, 210c, 220a, 220b, 230a und 230b, welche zwischen der Steuerung 100 und jedem der Benutzerschnittstellenobjekte 205a, 205b, 205c, 130, 140, 150 bzw. 160 zwischengeschaltet sind. Die Steuerung 100 sendet und empfängt Nachrichten an die und von den Assoziierungsobjekten, während die Assoziierungsobjekte Nachrichten an die und von den Benutzerschnittstellenobjekten senden bzw. empfangen, sowie an die und von der Steuerung 100. Die Assoziierungsobjekte stellen eine konsistente Schnittstelle zur Steuerung 100 dar. Entsprechend benötigt die Steuerung 100, anstatt Schnittstellencodeblöcke für jede der drei Arten von Benutzerschnittstellenobjekten aufzuweisen, welche in der Benutzerschnittstelle 110 (d. h. Tabellenobjekte, Textfeldobjekte und Ankreuzboxobjekte) enthalten sind, nur einen einzigen Schnittstellencodeblock, mit welchem sie mit jeglichem Assoziierungsobjekt kommunizieren kann. Umgekehrt sorgen die Assoziierungsobjekte für jede Konvertierung oder Übersetzung, welche zwischen Nachrichten, welche durch die Steuerung 100 gesendet und empfangen werden, und Nachrichten, welche durch die verschiedenen Benutzerschnittstellenobjekte gesendet und empfangen werden, erforderlich ist.
In dem in Fig. 2 gezeigten Ausführungsbeispiel der Erfindung wird für jedes Benutzerschnittstellenobjekt ein gesondertes Assoziierungsobjekt genutzt, selbst wenn es mehrere Benutzerschnittstellenobjekte der gleichen Art gibt. Somit werden in dem Ausführungsbeispiel von Fig. 2 gesonderte Textfeldassoziierungsobjekte 220a und 220b für jedes der Textfeldobjekte 130 bzw. 140 benutzt. In der gleichen Weise werden gesonderte Ankreuzboxassoziierungsobjekte 230a und 230b für jede der Ankreuzboxobjekte 150 bzw. 160 benutzt und werden gesonderte Tabellenspaltenassoziierungsobjekte 210a, 210b und 210c für jede Spalte von Tabelle 205 benutzt, welche in diesem Ausführungsbeispiel Tabellenspaltenobjekte 205a, 205b bzw. 205c umfaßt. In anderen Ausführungsbeispielen kann Tabelle 205 ein einziges Objekt umfassen und mit einer einzigen Assoziierung assoziiert werden.
Assoziierungsobjekte sind durch die vorliegende Erfindung bereitgestellte Objekte, welche durch einen Programmierer genutzt werden können, um ein Steuerungsobjekt an eine Vielfalt von verschiedenen Arten von Benutzerschnittstellenobjekten zu binden, ohne es für den Programmierer erforderlich zu machen, das Steuerungsobjekt mit dem Code auszustatten, welcher zum Kommunizieren mit jedem Typ von Benutzerschnittstellenobjekt notwendig ist. Das Steuerungsobjekt muß nur mit den Mitteln zum Senden von und Antworten auf Standardnachrichten ausgestattet werden. Umgekehrt sorgen die Assoziierungsobjekte für die Nachrichten-Sende- und Empfangserfordernisse, welche für jede Art von Benutzerschnittstellenobjekt spezifisch sind. Die objektorientierte Programmierumgebung, welche bei dem Ausführungsbeispiel von Fig. 2 benutzt wird, ist besonders geeignet für die Entwicklung von Datenbank- Anwendungsprogrammen. Das Verfahren der vorliegenden Erfindung kann jedoch auch für Nicht-Datenbank-Anwendungen verwendet werden.
Die Assoziierungsobjekte der vorliegenden Erfindung sind besonders nützlich in einer Programmierumgebung, welche dem Programmierer eine Auswahl von Benutzerschnittstellenobjekten bereitstellt. Die vorliegende Erfindung fügt eine vordefinierte Assoziierung für jedes Benutzerschnittstellenobjekt hinzu, welches durch die Programmierumgebung bereitgestellt wird. Ein Anwendungsprogrammierer, welcher Daten von einem Steuerungsobjekt anzuzeigen wünscht, kann auf einfache Weise eine geeignete Benutzerschnittstelle erzeugen, indem er das gewünschte Benutzerschnittstellenobjekt auswählt und es mit dem Steuerungsobjekt verbindet, wobei er das geeignete Assoziierungsobjekt für das ausgewählte Benutzerschnittstellenobjekt benutzt. Ein Programmierer kann auch kundenspezifische Benutzerschnittstellenobjekte und zugehörige Assoziierungsobjekte entwickeln.
Der Zweck einer Benutzerschnittstelle ist, einem Benutzer eine Datenausgabe anzuzeigen und eine Dateneingabe von einem Benutzer zu akzeptieren. Obwohl die spezifischen Mechanismen, wie Daten auf einer Benutzerschnittstelle angezeigt werden oder wie sie von einem Benutzer empfangen werden, abhängig von dem spezifischen Typ von verwendetem Benutzerschnittstellenobjekt variieren, ist der zu Grunde liegende Grundprozeß der gleiche: ein Benutzerschnittstellenobjekt empfängt Daten von einem Steuerungsobjekt und zeigt sie, in irgendeiner Weise, auf der Benutzerschnittstelle an; wenn eine Änderung durch den Benutzer auf der Benutzerschnittstelle vorgenommen wird, wird jene Änderung an das Steuerungsobjekt übertragen. Die vorliegende Erfindung ermöglicht dem Steuerungsobjekt, mit diesen zu Grunde liegenden Grundprozessen umzugehen, während sie das Steuerungsobjekt von jeglichen komplexeren Steuerungsanforderungen von besonderen Benutzerschnittstellenobjekten isoliert.
Ein Ausführungsbeispiel der vorliegenden Erfindung wird in "Enterprise Objects Framework (TM)" verwendet, einem Satz von Werkzeugen und Betriebsmitteln für die NEXTSTEP (TM) objektorientierte Programmierumgebung von NeXT Computer, Inc. Enterprise Objects Framework stellt Werkzeuge bereit, welche Programmentwickler befähigen, Datenbankanwendungen zu entwerfen, welche mit relationalen Datenbanken arbeiten, welche einfach zu bauen und zu warten sind, welche mit anderen Anwendungen kommunizieren und welche Standardschnittstellenmerkmale nutzen. Enterprise Objects Framework ist im Detail in Enterprise Objects Framework Developer's Guide (NeXT Computer, Inc., 1994) und Enterprise Objects Framework Reference (NeX'T Computer, Inc., 1994) beschrieben, wobei beide von diesen hier durch Bezugnahme enthalten sind.
Die Architektur und der Datenfluß einer Enterprise-Objects- Framework-Anwendung ist in Fig. 3 gezeigt. In der in Fig. 3 gezeigten Anwendung fließen Daten von einer relationalen Datenbank 300 zu einer Benutzerschnittstelle 360, und umgekehrt, und zwar über eine Anzahl von eingreifenden Modulen und Ebenen.
Der Datenfluß von der relationalen Datenbank 300 zur Benutzerschnittstelle 360 läuft wie folgt ab. Daten in der Form von Datenreihen von der relationalen Datenbank 300 werden von der relationalen Datenbank 300 zu einer Adapterebene 310 ausgelesen, wobei weitläufig bekannte Datenbank- Zugriffstechniken verwendet werden. Auf der Adapterebene 310 werden die von der relationalen Datenbank 300 empfangenen Rohdaten in "Verzeichnisobjekte" (dictionary objects) verpackt. Verzeichnisobjekte enthalten Schlüsselwertpaare: Jeder Schlüssel stellt typischerweise den Namen einer Datenbankspalte dar und der Schlüsselwert entspricht den Daten für die Spalte der bestimmten Reihe, welche von der relationalen Datenbank 300 ausgelesen wurde. Das Schlüsselwertkodierungsprotokoll, welches in Enterprise Objects Framework benutzt wird, ist unten in dem als Key-Value Coding Protocol (Schlüsselwertkodierungsprotokoll) bezeichneten Abschnitt beschrieben. Dieses Schlüsselwertkodierungsprotokoll ist auch in der paralell anhängigen U.S.-Patentanmeldung Nr. 08/353,524 "Dynamic Object Communication Protocol" beschrieben, welche am 7. Dezember 1994 eingereicht wurde und dem Bevollmächtigten der vorliegenden Erfindung zugewiesen ist und hier durch Bezugnahme enthalten ist. Wie in Fig. 3 gezeigt, werden Daten in der Form von diesen Verzeichnisobjekten von der Adapterebene 310 zu einer Datenbankebene 320 weitergeleitet.
Die Datenbankebene 320 erzeugt "Unternehmensobjekte" (enterprise objects) aus den Verzeichnisobjekten. Unternehmensobjekte sind wie andere Objekte, welche in objektorientierten Programmiersprachen verwendet werden, in welchen sie Daten mit Verfahren zum Bearbeiten jener Daten koppeln. Ein Unternehmensobjekt hat jedoch bestimmte Charakteristika, welche es von anderen Objektklassen unterscheidet. Ein Unternehmensobjekt hat Eigenschaften, welche gespeicherte Daten abbilden, und eine Instanz eines Unternehmesobjekts entspricht typischerweise einer einzelnen Reihe oder einem einzelnen Datensatz in einer Datenbank. Ferner weiß ein Unternehmensobjekt, wie es mit anderen Teilen des Enterprise Objects Framework wechselwirken muß, um Werte für seine Eigenschaften auszugeben und zu empfangen. Die Teile, aus welchen ein Unternehmensobjekt zusammengestellt ist, sind seine Klassendefinition und die Datenwerte für die Reihe oder den Datensatz, zu welcher/welchem es gehört. Der Mechanismus, welcher ein Unternehmensobjekt befähigt, seine Werte mit anderen Objekten auszutauschen, ist das Key Value Coding- Protokoll, auf welches oben Bezug genommen wurde und welches unten in dem als Key-Value Coding Protocol bezeichneten Abschnitt beschrieben ist. Das Key Value-Protokoll ermöglicht einem Objekt auch, seine Werte bei der Ausführungszeit von einem Verzeichnis zu setzen, wie unten beschrieben ist.
Wenn ein Objekt mit Werten von einem Verzeichnis zu laden ist, werden die Verfahrens- und Instanzvariablen des Objekts überprüft, um zu bestimmen, ob es eine Übereinstimmung zwischen Schlüsseln in dem Verzeichnis und dem Objekt gibt. Dies wird durch Suchen nach dem Verfahren "set (property)" (setzen (Eigenschaft)) verrichtet, wobei Eigenschaft der Spaltenname oder -schlüssel in dem Verzeichnis ist. Zum Beispiel sucht das System bei einer als "lastName" (Nachname) benannten Eigenschaft nach einem Verfahren in der Form "setlastName". Wenn es eine Übereinstimmung gibt, kann der Wert der Eigenschaft "lastName" unter Benutzung des setlastName- Verfahrens in das Objekt geladen werden.
Wenn kein Verfahren eine Übereinstimmung liefert, sucht das System nach einer Instanzvariable, deren Name der gleiche wie derjenige der Eigenschaft ist und setzt ihren Wert auf direkte Weise.
Wenn ein Verzeichnis mit Werten von einem Objekt zu laden ist, werden die Eigenschaften des Verzeichnisses als eine Matrix bereitgestellt. Für jede Eigenschaft werden die Verfahren des Objekts überprüft, um zu bestimmen, ob sie in der Form "property" (Eigenschaft) sind. Falls es eine Übereinstimmung gibt, wird der Wert des Objekts für jenes Verfahren an das Verzeichnis zurückgegeben. Falls es keine Übereinstimmung gibt, werden die Instanzen des Objekts überprüft. Falls eine Instanz gefunden wird, welche mit der Eigenschaft übereinstimmt, wird der Wert an das Verzeichnis zurückgegeben.

takeValuesFromDictionary

Das Verfahren zum Setzen von Werten in einem Objekt wird durch "takeValuesFromDictionary" implementiert. Dieses Verfahren wird auf dem Grundobjekt der Umgebung implementiert, so daß, in einem Klassenhierarchie-System, jedes Objekt das Verfahren erbt. In einem Ausführungsbeispiel verwenden die Default- Implementierungen der Schlüsselwertkodierungsverfahren die folgende Klassendefinition:
1. Das Schlüsselwertkodierungsverfahren sucht nach einem Zugriffsverfahren, welches auf dem Eigenschaftennamen basiert. Zum Beispiel sucht take ValuesFromDictionary: bei einer als lastName benannten Eigenschaft nach einem Verfahren der Form setLastName: (zu beachten ist, daß der erste Buchstabe des Eigenschaftennamens als Großbuchstabe gesetzt ist).
2. Falls das Schlüsselwertkodierungsverfahren kein Zugriffsverfahren findet, sucht es nach einer Instanzvariable, deren Name der gleiche wie derjenige der Eigenschaft ist und setzt ihren Wert auf direkte Weise oder liest diesen auf direkte Weise aus. Beim Setzen einer Instanzvariable behält takeValuesFromDictionary: den neuen Wert und gibt den Alten frei.
Das takeValuesFromDictionary-Verfahren kann implementiert werden, wie in dem Pseudocode beschrieben, welcher in dem als Pseudocode benannten Abschnitt bereitgestellt ist. Der Betrieb von takeValuesFromDictionary ist in den Flußdiagrammen der Fig. 6A, 6B und 6C dargestellt.

takeValuesFromDictionary-Ablauf

takeValuesFromDictionary wird dargestellt, in dem zuerst auf Fig. 6A Bezug genommen wird. Am Entscheidungsblock 602 wird das Argument "Alle Schlüsselwertpaare im Verzeichnis abgearbeitet?" gestellt. Dieser Schritt überprüft, um zu sehen, ob das Objekt für alle Verzeichnispaare überprüft worden ist. Falls das Argument am Entscheidungsblock 602 wahr ist, endet das System bei Schritt 612. Dies bedeutet, daß alle Verzeichnispaare für das Objekt abgearbeitet worden sind, und somit das Verfahren abgeschlossen ist. Falls das Argument am Entscheidungsblock 602 falsch ist, sind nicht alle Paare abgearbeitet worden. Bei Schritt 604 wird die Klassenbeschreibung für das Objekt erhalten und überprüft. Bei Schritt 606 wird "findMethod" ausgeführt, um zu bestimmen, ob das Objekt ein Setzverfahren mit einem Namen aufweist, welcher mit einer Eigenschaft des Schlüsselwertpaares übereinstimmt. Dieser Schritt ist in Fig. 6B in größerem Detail dargestellt.
Nachdem findMethod bei Schritt 606 ausgeführt worden ist, geht das System zu Entscheidungsblock 608 über. Am Entscheidungsblock 608 wird das Argument "Verfahren gefunden?" gestellt. Dieser Schritt geschieht, um zu bestimmen, ob es eine Übereinstimmung zwischen den Verfahren des Objekts und der Eigenschaft des Schlüsselwertpaares gegeben hat. Falls das Argument am Entscheidungsblock 608 wahr ist, ist eine Übereinstimmung gefunden worden und die Daten können in das Objekt geladen werden. Die Routine von Fig. 6A endet bei Schritt 612. Falls das Argument am Entscheidungsblock 608 falsch ist, stimmen keine Verfahren mit der Eigenschaft des Schlüsselwertpaares überein und das System muß dann die Instanzen des Objekts überprüfen. Dies wird durch Aufrufen von "findInstance" bei Schritt 610 erreicht. Dieser Schritt wird in Fig. 6C in größerem Detail dargestellt. Nachdem findInstance ausgeführt worden ist, endet das System bei Schritt 612.

findMethod-Ablauf

Schritt 606 von Fig. 6A "findMethod" ist in Fig. 6B in größerem Detail dargestellt. Der Prozeß "findMethod" wird verwendet, um die Verfahren des untersuchten Objekts zu untersuchen, um zu bestimmen, ob seine Verfahren mit den Eigenschaften der bearbeiteten Schlüsselwertpaare übereinstimmen. Bei Schritt 622 wird das Verfahren, nach welchem gesucht wird, als vom Typ "set" (setzen) plus der Eigenschaft des bearbeiteten Schlüssels (z. B. falls die Eigenschaft des Schlüsselwertpaares "lastName" ist, dann sucht das System nach "setLastName") definiert. Bei Schritt 624 wird die Klassenbeschreibung auf das Verfahren hin überprüft, nach welchem gesucht wird. Am Entscheidungsblock 626 wird das Argument "Verfahren gefunden?" gestellt. Dies geschieht, um zu bestimmen, ob das Objekt das Verfahren enthält, nach welchem gesucht wird. Falls das Argument falsch ist, endet findMethod bei Schritt 634 und kehrt zu Entscheidungsblock 626 von Fig. 6A zurück.
Falls das Argument am Entscheidungsblock 626 wahr ist, ist eine Übereinstimmung gefunden worden. Das System bei 628 bestimmt den Argumenttyp für das Verfahren. Bei Schritt 630 wird der Wert des Schlüsselwertpaares zu dem Argumenttyp konvertiert, falls notwendig. Bei Schritt 632 wird das Verfahren mit dem Wert als Argument aufgerufen, um den Datenwert in das Objekt zu laden. Bei Schritt 634 endet findNethod und kehrt zu takeValuesFromDictionary von Fig. 6A zurück.
findInstance-Ablauf
Schritt 610 von Fig. 6A "findInstance" ist in Fig. 6C dargestellt. In dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung werden die Verfahren eines Objektes zuerst überprüft, wenn sie versuchen, Daten zu laden. Falls keine passenden Verfahren gefunden werden, werden die Instanzvariablen unter Verwendung von "findInstance" untersucht. Bei Schritt 642 wird die Klassenbeschreibung des Objekts untersucht, um zu bestimmen, ob es eine Instanz gibt, welche gleich der Schlüsseleigenschaft des bearbeiteten Schlüsselwertpaares ist. Am Entscheidungsblock 644, wird das Argument "Instanz gefunden?" gestellt. Falls das Argument falsch ist, das heißt, falls keine Instanzen mit der Eigenschaft übereinstimmen, endet der findInstance-Prozeß bei Schritt 644 und kehrt zu Schritt 612 von Fig. 6A zurück.
Falls das Argument am Entscheidungsblock 644 wahr ist, ist eine Übereinstimmung zwischen Instanzvariable und der Schlüsselwerteigenschaft gefunden worden. Das System bestimmt dann bei Schritt 646 den Instanztyp. Bei Schritt 648 wird der Speicher-Offset der Instanz in dem Objekt bestimmt. Bei Schritt 650 wird der Wert des untersuchten Schlüsselwertpaares zu dem Instanztyp des Objekts konvertiert. Bei Schritt 652 wird der Wert von dem Schlüsselwertpaar der Instanz in dem Objekt zugewiesen, wobei das vorher bestimmte Instanz-Offset verwendet wird. Bei Schritt 654 endet findInstance und kehrt zu Schritt 612 von Fig. 6A zurück.

valuesForKeys

Das Verfahren zum Laden eines Verzeichnisses mit Werten von einem Objekt ist "valuesForKeys". Die Klassendefinitionen für valuesForKeys sind wie oben für "takeValuesForDictionary" beschrieben. Das valuesForKeys-Verfahren kann implementiert werden, wie in dem Pseudocode (siehe den als Pseudocode bezeichneten Abschnitt unten) beschrieben. Der Betrieb, von valuesForKeys ist in den Flußdiagrammen von Fig. 7A, 7B und 7C dargestellt.

valuesForKeys-Ablauf

valuesForKeys wird dargestellt, indem zuerst auf Fig. 7A Bezug genommen wird. Wenn valuesForKeys aufgerufen wird, geschieht es, um Daten von einem Objekt zu nehmen und in ein Datenziel (z. B. eine relationale Datenbank) zu laden. Die Eigenschaften der Schlüssel des Schlüsselwertverzeichnisses des Datenziels werden in eine Schlüsselmatrix gegeben. Am Entscheidungsblock 720 wird das Argument "Alle Schlüssel in Schlüsselmatrix abgearbeitet?" gestellt. Falls das Argument wahr ist, sind alle Matrixeinträge abgearbeitet worden und das Verfahren ist zu Ende und der Prozeß endet bei Schritt 714. Falls das Argument falsch ist, wird der nächste Schlüssel in der Schlüsselmatrix abgearbeitet. Bei Schritt 704 erhält das System die Klassenbeschreibung für das Objekt. Bei Schritt 706 wird "returnMethod" ausgeführt, um zu bestimmen, ob das Objekt irgendwelche Verfahren (z. B. setValue, getValue, etc.) aufweist, welche mit der Schlüsseleigenschaft übereinstimmen. Dieser Schritt ist in Fig. 7B in größerem Detail dargestellt.
Nachdem returnMethod bei Schritt 706 ausgeführt worden ist, kehrt das System zu Entscheidungsblock 708 zurück. Am Entscheidungsblock 708 wird das Argument "Verfahren gefunden?" gestellt. Dieser Schritt geschieht, um zu bestimmen, ob es eine Übereinstimmung zwischen irgendeinem der Verfahren des Objekts und der Schlüsseleigenschaft gegeben hat. Falls das Argument am Entscheidungsblock 708 wahr ist, ist eine Übereinstimmung gefunden worden und die Daten können in das Datenziel geladen werden. Der Prozeß endet dann bei Schritt 714. Falls das Argument am Entscheidungsblock 708 falsch ist, stimmen keine Verfahren mit der Schlüsseleigenschaft überein. Das System überprüft dann die Instanzvariablen auf Übereinstimmungen. Dies wird durch Aufrufen von "returnInstance" bei Schritt 710 erreicht. Dieser Schritt ist in Fig. 7C in größerem Detail dargestellt. Nachdem returnInstance ausgeführt worden ist, speichert der Prozeß den Schlüssel und den zurückgegebenen Wert als ein Schlüsselwertpaar in dem Schlüsselwertverzeichnis. Bei Schritt 714 endet valuesForKeys.

returnMethod-Ablauf

Schritt 706 von Fig. 7A "returnNethod" ist in Fig. 7B dargestellt. Der Prozeß "returnMethod" wird benutzt, um die Verfahren des Objekts zu überprüfen, um zu bestimmen, ob irgendeines; seiner Verfahren mit der Eigenschaft des bearbeiteten Schlüsseleigenschaftsmatrixwerts übereinstimmt. Bei Schritt 722 wird das zu suchende Verfahren als eines definiert, welches die aktuelle Schlüsseleigenschaft aufweist. Bei Schritt 724 wird die Klassenbeschreibung auf das definierte Verfahren hin überprüft. Am Entscheidungsblock 726 wird das Argument "Verfahren gefunden?" gestellt. Falls das Argument falsch ist, gibt es keine Übereinstimmung, returnNethod endet bei Schritt 734 und kehrt zu valuesForKeys von Fig. 7A zurück.
Falls das Argument wahr ist, bei Schritt 728, ist eine Übereinstimmung gefunden worden. Bei Schritt 728 wird der Werttyp des Verfahrens bestimmt. Bei Schritt 730 wird das Verfahren aufgerufen und gibt das Ergebnis als Wert zurück. Bei Schritt 732 konvertiert der Prozeß den Wert zu einem Werttyp, falls notwendig, und der Wert kann in das Datenziel geladen werden. Der returnMethod-Prozeß endet bei Schritt 734.

returnInstance-Ablauf

Schritt 710 von Fig. 7A, "returnInstance" ist in Fig. 7C dargestellt. In dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung wird dieser Prozeß nur aufgerufen, wenn keine übereinstimmenden Verfahren für eine bearbeitete Schlüsseleigenschaft gefunden worden sind. Bei Schritt 742 wird die Klassenbeschreibung überprüft, um zu bestimmen, ob es eine Instanzvariable gibt, welche mit der Schlüsseleigenschaft übereinstimmt. Am Entscheidungsblock 744 wird das Argument "Instanz gefunden?" gestellt. Falls das Argument falsch ist, sind keine Übereinstimmungen gefunden worden, der returnInstance-Prozeß endet bei Schritt 752 und kehrt zu valuesForKeys von Fig. 6A zurück.
Falls das Argument am Entscheidungsblock 744 wahr ist, gibt es eine Übereinstimmung einer Instanzvariable und der Schlüsseleigenschaft. Bei Schritt 746 wird der Typ der Instanzvariable bestimmt. Bei 748 wird der Speicher-Offset der Instanzvariable in dem Objekt bestimmt. Bei Schritt 750 wird der Wert der Instanz zu einem Instanztyp konvertiert und kann in ein Schlüsselwertpaar des Verzeichnisses des Datenziels geladen werden. Bei Schritt 752 endet returnInstance und kehrt zu valuesForKeys von Fig. 7A zurück.
Zurückkommend auf Fig. 3, werden die Unternehmensobjekte, welche auf Datenbankebene 320 erzeugt wurden, von der Datenbankebene 320 zu einer Datenquelle 330 weiterleitet. Die Datenquelle 330 ist ein Objekt, welches die Fähigkeit aufweist, Unternehmensobjekte abzurufen, einzufügen, zu aktualisieren (update) und zu löschen. Änderungen, welche durch die Datenquelle 330 an einem Unternehmensobjekt vorgenommen wurden, werden über die Datenbankebene 320 und die Adapterebene 310 zur relationalen Datenbank 300 hinuntergeleitet, so daß für eine an einem Unternehmensobjekt vorgenommene Änderung eine entsprechende Änderung an der Datenbank vorgenommen wird.
Die Datenquelle 330 liefert Unternehmensobjekte, welche auf der Datenbankebene 320 erzeugt wurden, an eine Steuerung 340. Wie in Fig. 3 gezeigt, transportiert die Steuerung 340 Daten in der Form von Werten (values) von den Unternehmensobjekten zu einer Benutzerschnittstelle 360 über Assoziierungsobjekte 350. Die Steuerung 340 koordiniert die Werte, welche in der Benutzerschnittstelle angezeigt werden, mit den entsprechenden Unternehmensobjektwerten. Wenn Unternehmensobjekte modifiziert werden, teilt die Steuerung 340 dies der Datenquelle 330 mit, welche dafür verantwortlich ist, Änderungen an relationale Datenbank 300 zu verbreiten. Eine Beschreibung der Steuerungsobjektklasse, welche durch Enterprise Objects Framework bereit gestellt wird, ist unten in dem als Controller Object Class (Steuerungsobjektklasse) bezeichneten Abschnitt bekannt gemacht.
Datenbewegung in der in Fig. 3 gezeigten Architektur ist bidirektional. Änderungen, welche von einem Benutzer an Datenwerten, welche auf einer Benutzerschnittstelle 360 angezeigt werden, vorgenommen werden, breiten sich zur relationalen Datenbank 300 in der entgegengesetzten Richtung aus, wie Daten sich von der Datenbank 300 zur Benutzerschnittstelle 360 ausbreiten.
Wie oben erwähnt ist der Mechanismus, durch welchen Daten sich durch eine Enterprise-Object-Framework-Anwendung bewegen, ein informelles Schlüsselwertkodierungsprotokoll. Ungeachtet ihrer Charakteristika haben Objekte, welche sich dem Schlüsselwertkodierungsprotokoll angleichen (etwa wie Unternehmensobjekte), ein gemeinsames Charakteristikum: Auf ihre Daten wird durch andere Objekte in der Form von Schlüsselwertpaaren zugegriffen. Schlüsselwertkodierungsverfahren befähigen ein Objekt, Werte für seine Schlüssel zu empfangen und seine Schlüsselwerte an andere Objekte auszugeben.
Durch Verwendung von Schlüsselwertkodierung können verschiedene Typen von Objekten sich gegenseitig ihre Werte weiterleiten und dabei Daten durch die verschiedenen in Fig. 3 gezeigten Ebenen transportieren. Fig. 4 zeigt, wie die Eigenschaften in einem Unternehmensobjekt 420 den Schlüsselwertpaaren in einem Verzeichnis 410 entsprechen und wie beide umgekehrt einer Reihe in einer relationalen Datenbank 400 entsprechen. Unternehmensobjekteigenschaften- und Verzeichnisschlüssel (wie etwa firstName (Vorname) und lastName, gezeigt in Fig. 4) bilden Spalten in der Datenbank ab; der Wert für jeden Schlüssel (zum Beispiel "Lesly" bzw. "Oswald") stimmt mit dem Spaltenwert für die entsprechende Reihe überein.
Die Benutzerschnittstelle 360 von Fig. 3 enthält typischerweise eine Anzahl von Benutzerschnittstellenobjekten, wie etwa Popup-Listen, Formulare, Textfelder und Tabellen. Diese Benutzerschnittstellenobjekte zeigen die Schlüsselwerte von Unternehmensobjekten an und kommunizieren, falls die Werte in der Benutzerschnittstelle editiert werden, die Änderungen zurück an die Unternehmensobjekte.
Die Schnittstelle zwischen Benutzerschnittstellenobjekten und zugehörigen Unternehmensobjekten wird durch ein Steuerungsobjekt 340 und Assoziierungsobjekte 350 von Fig. 3 bereitgestellt, welche zusammen als eine Schnittstellenebene zwischen Unternehmensobjekten und Benutzerschnittstellenobjekten gesehen werden können.
Der primäre Actor (primary actor) in der Schnittstellenebene ist die Steuerung 340. Die Steuerung 340 benutzt Assoziierungsobjekte, um zwischen Unternehmensobjekten und der Benutzerschnittstelle 360 zu vermitteln. Jedes Assoziierungsobjekt verbindet ein einzelnes Benutzerschnittstellenobjekt mit einem Klasseneigenschaftsnamen (Schlüssel) in einem Unternehmensobjekt oder Objekten, welche durch die Steuerung verwaltet werden. Der Eigenschafts (Schlüssel)-wert wird in dem Benutzerschnittstellenobjekt angezeigt, mit welchen das Assoziierungsobjekt verbunden ist. Enterprise Objects Framework stellt dem Entwickler eine Anzahl von vordefinierten Assoziierungsobjekten und assoziierten Benutzerschnittstellenobjekten bereit. Der als Association Objects (Assoziierungsobjekte) bezeichnete Abschnitt (unten) enthält Beschreibungen von Assoziierungsobjekten, welche durch Enterprise Objects Framework bereitgestellt werden. Spezifische Assoziierungsobjekte, welche durch Enterprise Objects Framework bereitgestellt werden, umfassen EOAssociation (eine abstrakte Assoziierungsobjektklasse) und die Unterklassen EOActionCellAssociation, EOColumnAssociation; EOControl- Association; EOImageAssociation; EOMatrixAssociation, EOPopUp- Association; EOQualifiedAssociation; und EOTextAssociation.
Wie oben beschrieben bindet ein Assoziierungsobjekt ein einzelnes Benutzerschnittstellenobjekt (wie etwa ein Textfeld) an einen Wert, welcher einem Schlüssel in einem Unternehmensobjekt oder Objekten, welche durch das Steuerungsobjekt verwaltet werden, entspricht. Zum Beispiel kann ein Textfeld den Wert "Jun-19-1992" für den Schlüssel "hireDate" (Einstellungsdatum) des Unternehmensobjekts 420 aus Fig. 4 anzeigen. Ein Assoziierungsobjekt ist mit einem geeigneten Schlüssel ausgestattet, um es zu befähigen, Daten von einem datentragenden Objekt zu erhalten, und zwar unter Benutzung eines Schlüsselwertkodierungsprotokolls. Mittels Assoziierungsobjekten und ihren Schlüsseln und des Schlüsselwertkodierungssystems kann eine Steuerung Daten von datentragenden Objekten zu Benutzerschnittstellenobjekten versetzen und Daten von Benützerschnittstellenobjekten in datentragende Objekte auslesen. Die Benutzerschnittstellenobjekte, Assoziierungsobjekte und Schlüssel können ohne Daten assembliert werden und für spätere Verwendung mit einem Anwendungsprogramm archiviert werden. Durch Verwendung des Schlüsselwertkodierungsprotokolls können diese Objekte vorzeitig assembliert und konfiguriert werden und ohne Kompilierung zur Ausführungszeit zur Ausführung gebracht werden.
Eine der durch Assoziierungsobjekte durchgeführten Funktionen, falls benötigt, ist, Werte zu konvertieren, welche durch die Steuerung von einem Unternehmensobjekt extrahiert und zu einem Assoziierungsobjekt weitergeleitet wurden, und zwar zu einem Typ, welcher durch das entsprechende Benutzerschnittstellenobjekt angezeigt werden kann. In gleicher Weise konvertiert eine Datenquelle editierte Werte, welche von einem Assoziieungsobjekt an die Steuerung zurückgegeben wurden, zu einer geeigneten Wertklasse, welche durch die Datenquelle auf das entsprechende Unternehmensobjekt angewendet werden kann.
Eine Steuerung arbeitet in enger Weise mit ihrem Assoziierungsobjekten, um sicherzustellen, daß Werte, welche in der Benutzerschnittstelle angezeigt werden, mit den entsprechenden Unternehmensobjektwerten synchronisiert bleiben. Wenn sich ein Unternehmensobjektwert ändert, teilt dies die Steuerung ihren Assoziierungsobjekten mit. Umgekehrt, wenn ein Assoziierungsobjekt von einer Änderung in einem angezeigten Wert durch sein Benutzerschnittstellenobjekt benachrichtigt wird, informiert das Assoziierungsobjekt seine Steuerung von der Änderung, welche aufgetreten ist.
Fig. 5 zeigt die Sequenz an Schritten, welche auftreten, wenn der durch ein Benutzerschnittstellenobjekt angezeigte Wert sich geändert hat. Die Sequenz beginnt, wenn ein Benutzer den Wert eines angezeigten Benutzerschnittstellenobjekts bei Block 500 ändert. Zum Beispiel kann ein Benutzer das hire-Datum "Jun-19- 1992", welches in einem Textfeldobjekt für das Unternehmensobjekt 420 von Fig. 4 angezeigt wird, zu einem neuen Datum "Jun-19-1991" ändern, indem er das neue Datum in dem Textfeldobjekt eingibt, welches auf der Benutzerschnittstelle angezeigt wird.
Als Antwort auf diese Änderung, bei Block 510 von Fig. 5, sendet das Benutzerschnittstellenobjekt seinem Assoziierungsobjekt (in diesem Ausführungsbeispiel gibt es eine Eins-zu- Eins-Korrespondenz zwischen Benutzerschnittstellenobjekten und Assoziierungsobjekten) eine Nachricht, daß diese benutzerinitiierte Änderung aufgetreten ist. Das Assoziierungsobjekt, bei Block 520, benachrichtigt wiederum seine Steuerung von der Änderung, indem es der Steuerung eine "associationDidEdit"-Nachricht sendet. Eine "associationDid- Edit"-Nachricht informiert die Steuerung, daß eine Änderung aufgetreten ist, aber umfaßt nicht den neuen Wert. Um den neuen Wert zu erhalten, sendet die Steuerung dem benachrichtigenden Assoziierungsobjekt eine "value"-Nachricht bei Block 530, auf welche hin das Assoziierungsobjekt den neuen Wert bei Block 535 zurücksendet.
Nachdem sie den neuen Wert erhalten hat, sendet die Steuerung ihrer Datenquelle eine "coerceValue:forKey;"-Nachricht bei Block 540. Diese Nachricht veranlaßt die Datenquelle, den neuen, von dem Assoziierungsobjekt erhaltenen Wert zu einem Wertklassentyp zu konvertieren, welcher durch das entsprechende Unternehmensobjekt benutzt werden kann. Die Steuerung liefert dann den neuen, konvertierten Wert an das Unternehmensobjekt mittels einer "takeValuesFromDictionary:"-Nachricht bei Block 550 aus. "takeValuesFromDictionary" ist eine Standardnachricht, welche Teil des Schlüsselwertkodierungsprotokolls ist, welches benutzt wird, um Daten zwischen Objekten in dem Enterprise Objects Framework zu übertragen.
Als Nächstes sendet die Steuerung "updateObject:"- und "saveObjects"-Nachrichten an ihre Datenquelle bei Block 560. Als Antwort auf diese Nachrichten veranlaßt die Datenquelle die Daten in der Datenbank aktualisiert und gespeichert zu werden, um den neuen Wert wiederzugeben.
Obwohl die obige Sequenz an Schritten als ohne Pufferung stattfindend beschrieben worden ist, können Pufferungstechniken, welche in dem Fachgebiet weithin bekannt sind, bei verschiedenen Schritten entlang der Sequenz verwendet werden. Zum Beispiel können Änderungen, welche in den Benutzerschnittstellenobjekten vorgenommen werden, gepuffert werden, bevor sie gesendet werden, um Unternehmensobjekte zu aktualisieren, oder Änderungen an den Unternehmensobjekten können ohne Pufferung vorgenommen werden, während das Senden der Änderungen zu der Datenquelle gepuffert wird.
Da jedes Benutzerschnittstellenobjekt ein entsprechendes Assoziierungsobjekt aufweist, und da eine Benutzerschnittstelle typischerweise eine Anzahl von Benutzerschnittstellenobjekten aufweist, wird eine Steuerung typischerweise mit einer Anzahl von Assoziierungsobjekten assoziiert sein. Ferner können eine Anzahl von verschiedenen Benutzerschnittstellenobjekten einen Wert für den gleichen Schüssel eines Unternehmensobjekts anzeigen. Als Ergebnis kann, falls ein Wert, welcher durch eines der Benutzerschnittstellenobjekte angezeigt wird, durch einen Benutzer geändert wird, diese Änderung in anderen Benützerschnittstellenobjekten wiedergegeben werden. Entsprechend sendet die Steuerung, nachdem der Wert in einem Unternehmensobjekt als Antwort auf einen neuen, durch den Benutzer eingegebenen Wert geändert worden ist, allen ihren Assoziierungsobjekten "contentsDidChange"-Nachrichten bei Block 570. Zusätzlich sendet die Steuerung, falls die Änderung im Wert auch verursacht, daß sich das ausgewählte Unternehmensobjekts ändert (ein "ausgewähltes" Unternehmensobjekt ist das aktuelle Objekt, für welches Werte in der Benutzerschnittstelle angezeigt werden, oder, im Falle, daß ein Benutzerschnittstellenobjekt Werte für Mehrfach- Unternehmensobjekte simultan anzeigt, wie etwa eine Tabelle, ist das ausgewählte Unternehmensobjekt das Objekt, dessen Werte hervorgehoben sind), auch allen ihren Assoziierungsobjekten eine "selectionDidChange"-Nachricht bei Block 580. Dies befähigt jedes Assoziierungsobjekt Werte für das aktuell ausgewählte Unternehmensobjekt anzuzeigen, oder die Werte für das ausgewählte Unternehmensobjekt hervorzuheben, falls das Benutzerschnittstellenobjekt, welches mit dem Assoziierungsobjekt assoziiert ist, Werte für Mehrfach-Unternehmensobjekte anzeigt.
Eine von einem Assozierungsobjekt empfangene "contentsDidChange"-Nachricht bildet für das Assoziierungsobjekt ein Signal, daß sich der durch sein Benutzerschnittstellenobjekt angezeigte Wert geändert haben kann. Um zu bestimmen, ob die aufgetretene Änderung den Wert beeinflußt, welchen ein Assoziierungsobjekt in seinem Benutzerschnittstellenobjekt anzeigt, bei Block 585, sendet jedes Assoziierungsobjekt der Steuerung eine "valuesForKeys"- Nachricht, um den aktuellen Wert für den Schlüssel zu erhalten, welcher in dem Benutzerschnittstellenobjekt des Assoziierungsobjeks angezeigt wird. "valuesForKeys" ist wie "takeValuesFromDictionary" eine Standardnachricht, welche Teil des Schüsselwertkodierungsprotokolls ist, welches benutzt wird, um Daten zwischen Objekten in dem Enterprise Objects Framework zu übertragen. Wenn ein Assoziierungsobjekt den aktuellen Wert für sein Benutzerschnittstellenobjekt empfängt, vergleicht es den aktuellen Wert mit dem letzten Wert, welchen sie empfangen hat (welcher gewöhnlicherweise auch der Wert sein würde, welcher durch sein Benutzerschnittstellenobjekt angezeigt wird) bei Block 590. Wenn der aktuelle Wert verschieden von dem letzten Wert ist, sendet das Assoziierungsobjekt eine Nachricht an sein Benutzerschnittstellenobjekt, um den angezeigten Wert auf den neuen Wert bei Bock 595 zu aktualisieren.
Aus der Sicht der Steuerung sehen alle Assoziierungsobjekte gleich aus: Die Steuerung kommuniziert mit allen Assoziierungsobjekten unter Benutzung des gleichen Satzes von Standardnachrichten. Der in Fig. 5 gezeigte Prozeß, insbesondere von Block 520 aus vorwärts, wendet sich somit im Allgemeinen auf jegliche WertÄnderung an, welche an jeglichem Benutzerschnittstellenobjekt vorgenommen wird. Die Weise, in welcher ein Benutzerschnittstellenobjekt mit seinem Assoziierungsobjekt wechselwirkt, und die spezifischen Nachrichten, welche für Kommunikationen zwischen Assoziierungsobjekt und seinem Benutzerschnittstellenobjekt verwendet werden, werden jedoch variieren und zwar abhängig von den Charakteristika, welche für ein bestimmtes Benutzerschnittstellenobjekt spezifisch sind. Entsprechend kann die bestimmte Art, mit welcher die in den Blöcken 500 und 510 gezeigten Schritte durchgeführt werden, von Assoziierungsobjekt zu Assoziierungsobjekt variieren.
Zusätzlich zum Informieren seiner Assoziierungsobjekte, wenn seine Unternehmensobjekte oder ein aktuell ausgewähltes Unternehmensobjekt sich geändert haben/hat, verwendet eine Steuerung im Enterprise Objects Framework ein "endEditing"- Verfahren, um seine Assoziierungsobjekte anzuweisen, das Editieren abzuschließen. Bevor eine Steuerung bestimmte Operationen durchführen kann (wie etwa Abrufen, Einfügen eines neuen Unternehmensobjekts oder Setzen einer Undo-Markierung) muß es jegliche neue Editierungen von seinen Assoziierungsobjekten aufsammeln. Wenn die Steuerung "endEditing"-Nachrichten an ihre Assoziierungsobjekte sendet, beenden sie das Editieren, geben den Erst-Responder-Status (first responder status) ab und benachrichtigen die Steuerung von jeglichen Änderungen mit "associationDidEdit:". Das Protokoll, welches durch eine Steuerung benutzt wird, um Benachrichtigungsnachrichten an ihre Assoziierungsobjekte zu senden, ist unten in dem als Notification Protocol (Benachrichtigungsprotokoll) bezeichneten Abschnitt beschrieben.
Zusätzlich zum Bereitstellen einer Anzahl von vordefinierten Benutzerschnittstellenobjekten und Assoziierungsobjekten, ermöglicht, Enterprise Objects Framework einem Entwickler kundenspezifische Benutzerschnittstellenobjekte und assoziierte benutzerspezifische Assoziierungsobjekte zu erzeugen. Das "EOAssociation"-Objekt, welches unten in dem als Association Objects (Assoziierungsobjekte) bezeichneten Abschnitt beschrieben ist, kann durch einen Entwickler als eine Basis zum Definieren eines kundenspezifischen Assoziierungsobjekts verwendet werden.
Somit ist ein Verfahren zum Assoziieren von Steuerungs- und datentragenden Objekten mit Benutzerschnittstellenobjekten präsentiert worden. Obwohl die vorliegende Erfindung hinsichtlich bestimmter beispielhafter Ausführungsbeispiele beschrieben worden ist, wird für Fachleute ersichtlich sein, daß die vorliegende Erfindung nicht auf diese spezifischen Ausführungsbeispiele beschränkt ist. Zum Beispiel können die Assoziierungsobjekte der vorliegenden Erfindung, anstatt mit datentragenden Objekten über ein Steuerungsobjekt zu kommunizieren, direkt mit datentragenden Objekten kommunizieren. Anstatt ein getrenntes Assoziierungsobjekt für jedes Benutzerschnittstellenobjekt zu verwenden, kann ein Assoziierungsobjekt mit mehr als einem Benutzerschnittstellenobjekt assoziiert werden. Die spezifischen Nachrichten, welche von Assoziierungsobjekten und datentragenden und datensteuernden Objekten gesendet und empfangen werden, können von den spezifischen, hier beschriebenen Nachrichten abweichen. Die spezifischen, hier beschriebenen Schritte und Schrittsequenzen können durch einen Benutzer konfiguriert werden und können von einem Ausführungsbeispiel zu einem anderen abweichen. Andere Ausführungsbeispiele, welche die erfinderischen Merkmale der vorliegenden Erfindung umfassen, werden für Fachleute ersichtlich sein.

Kategoriebeschreibung

Die Verfahren der EOKeyValueCoding-Kategorie bilden den Hauptübertragungsmechanismus für Daten im Enterprise Objects Framework, in welchem auf die Eigenschaften eines Unternehmensobjekts indirekt durch den Namen zugegriffen wird, anstatt direkt durch Aufruf eines Zugriffsverfahrens oder als Instanzvariablen. Somit kann jegliches Objekt seinen Zustand als ein NSDictionary (NSVerzeichnis) darstellen, dessen Schlüssel die Namen von seinen Eigenschaften sind.
Das Verfahren zum Setzen von Unternehmensobjektswerten ist takeValuesFromDictionary:, welches die Schlüssel des eingegangenen Verzeichnisses verwendet, um die neuen Werte für die Objekteigenschaften zu identifizieren. Das Verfahren zum Erhalten von Werten ist valuesForKeys:, welches den Wert für jeden Schlüssel in der eingegangenen Matrix extrahiert und die Schlüsselwertpaare in ein Verzeichnis zurückgibt. Diese zwei Verfahren sind sowohl für NSObject als auch Object definiert, um die Zugriffsverfahren zu verwenden, welche normalerweise durch Objekte implementiert sind (oder um direkt auf Instanzvariablen zuzugreifen, falls erforderlich), so daß Sie keinen speziellen Code schreiben müssen, nur um ihre Unternehmensobjekte in das Framework zu integrieren. Ihre Unternehmensobjekte können auch die Default-Implementierungen außer Kraft setzen, um benutzerspezifische Bearbeitung von Werten zu verrichten, wenn sie die Objekte betreten und diese verlassen.

Default-Implementierungen

Das Framework stellt Default-Implementierungen von takeValuesFromDictionary: und valuesForKeys: bereit, welche für alle Objekte funktionieren. Die Implementierungen für EOGenericRecord sind recht einfach: Sie speichern einfach die Eigenschaften in einem Verzeichnisobjekt, welches durch den EOGenericRecord (EOGenerischerDatensatz) gehalten wird, oder lesen diese einfach aus. NSDictionary und NSMutableDictionary (NSMutationsfähigesVerzeichnis), obwohl nicht geeignet zur Benutzung als Unternehmensobjekte, implementieren diese Verfahren auf bedeutungsvolle Weise, indem sie direkt auf ihre Schlüsselwertpaare zugreifen. Die Implementierungen für Object und NSObject, andererseits, handhaben die abgefragten Schlüssel auf dynamische Weise, basierend auf der Definition der Empfängerklasse. Diese Implementierungen sind allgemein genug, daß Ihre Unternehmensobjektklassen selten ein Schlüsselwertkodierungsverfahren außer Kraft setzen müssen sollten.
Beim Zugriff auf eine Objekteigenschaft benutzen die Default-Implementierungen des Schlüsselwertkodierungsverfahrens die folgende Klassendefinition:
1. Das Schlüsselwertkodierungsverfahren sucht nach einem Zugriffsverfahren, welches auf dem Eigenschaftennamen basiert. Zum Beispiel bei einer als lastName benannten Eigenschaft, sucht takeValuesFromDictionary: nach einem Verfahren der Form setLastName: (beachten Sie, daß der erste Buchstabe des Eigenschaftennamens als Großbuchstabe gesetzt ist) und valuesForKeys: sucht nach einem Verfahren der Form lastName.
2. Falls das Schlüsselwertkodierungsverfahren kein Zugriffsverfahren findet, sucht es nach einer Instanzvariable, deren Name der Name wie derjenige der Eigenschaft ist und setzt ihren Wert direkt oder liest diesen direkt aus. Beim Setzen einer Instanzvariable behält takeValuesFromDictionary: den neuen Wert und gibt den Alten frei.

Typ-Überprüfung und Typ-Konvertierung

Die Default-Implementierungen der Schlüsselwertkodierungsverfahren akzeptieren jeglichen Id-Typ als einen Wert und nehmen keine Typ-Überprüfung oder Typ- Konvertierung unter Objektklassen vor. Es ist zum Beispiel möglich, einen NSString (NSZeichenkette) an takeValuesFromDictionary: als den Wert für eine Eigenschaft weiterzuleiten, von welcher der Empfänger erwartet, daß sie ein NSDate (NSDatum) ist. Der Sender einer Schlüsselwertkodierungsnachricht ist somit dafür verantwortlich, sicherzustellen, daß die Werte von der richtigen Klasse sind. Ein EOController, zum Beispiel, konvertiert Zeichenkettenwerte von der Benutzerschnittstelle mit seinem coerceValue:forKey:-Verfahren der Datenquelle. Falls Sie eine Datenquelle verwenden, um Ihre Unternehmensobjekte zu verwalten, können Sie dieses Verfahren ebenso benutzen. Beachten Sie, daß, falls Sie die Zugriffsebene des Frameworks benutzen, von einem EOModel (EOModell) bestimmen können, welche Wertklasse mit jedem Attribut assoziiert ist - EODatabaseDataSource (EODatenbankDatenQuelle) benutzt diese Information in seiner Implementierung von coerceValue:forKey:.
Die Schlüsselwertkodierungsverfahren handhaben einen speziellen Fall bezüglich Werttypen. Numerische Werte müssen in Verzeichnissen als NSNumber (NSZiffern)- Objekte übermittelt werden, sind aber nicht sehr effizient für Berechnung oder Speicherung; die meisten Objekte speichern numerische Eigenschaften als C-Skalar (Ziffern)-Typen und deklarieren ihre Zugriffsverfahren, um sie in jener Form zu handhaben. Zusätzlich dazu, daß sie als NSNumbers in Verzeichnissen dargestellt werden, werden numerische Eigenschaftenwerte durch einen EOController als NSString- Objekte gehandhabt. Da numerische Eigenschaften sehr üblich sind, konvertieren die Default-Implementierungen des Schlüsselwertkodierungsverfahrens einen Objektwert zu dem C-Skalar (Ziffern)-Typ, welcher durch das Zugriffsverfahren oder die Instanzvariable des Unternehmensobjekts gefordert ist. Nehmen Sie zum Beispiel an, daß Ihr Unternehmensobjekt diese Zugriffsverfahren definiert:
- (void)netSalary:(unsigned int)salary
- (unsigned int)salary
Für das setSalary:-Verfahren konvertiert takeValuesFromDictionary: den Objektwert für den "salary"-Schlüssel in dem Verzeichnis zu einem unsigned int (vorzeichenlosen Int) und leitet es als salary weiter. Gleichermaßen konvertiert valuesForKeys: den Rückgabewert des salary-Verfahrens zu einer NSNumber und fügt jene in das Verzeichnis ein, welches es zurückgibt.
Die Default-Implementierungen uriterstützen die folgenden Skalar-Typen:
char unsigned char
short unsigned short
int unsigned int
long unsigned long
float double
Objektwerte werden zu diesen Typen mit den Standardnachrichten charValue, intValue, floatValue usw. konvertiert. Beachten Sie, daß die Schlüsselwertkodierungsverfahren nicht überprüfen, daß ein Objektwert tatsächlich auf diese Nachrichten antwortet; dies kann zu Laufzeitfehlern führen, falls das Objekt nicht auf die geeignete Nachricht antwortet.
Ein wichtiger, zu berücksichtigender Punkt beim Benutzen von C-Skalar-Typen ist, daß die meisten relationalen Datenbanken die Verwendung eines NULL-Wertes ermöglichen, welcher verschieden von jeglichem numerischen Wert ist und in dem Enterprise Objects Framework durch die EONull-Klasse dargestellt wird. Da die C-Skalar-Typen keinen verschiedenen NULL-Wert fassen können, erheben die Defäult-Implementierungen der Schlüsselwertkodierungsverfahreri NSInvalidArgumentException beim Zusammentreffen mit einem EONull-Objekt, welches konvertiert werden muß. Sie sollten entweder Ihre Datenbank so entwerfen, daß sie NULL-Werte für numerische Spalten nicht verwendet oder Ihre Unternehmensobjektklasse so entwerfen, daß sie NSNumber-Objekte benutzt, wo NULL-Werte erlaubt sind.

Implementieren von Schlüsselwertkodierungsverfahren

Ihre eigenen Unternehmensobjektklassen können entweder auf dem Default-Verhalten ihrer Oberklasse beruhen oder es außer Kraft setzen, teilweise oder vollständig. Zum Beispiel kann eine Unterklasse von NSObject ein paar Eigenschaften aufweisen, welche sie auf eine spezielle Weise handhaben muß, wobei aber der ganze Rest durch die Default-Implementierung gehandhabt werden kann. In diesem Fall könnten Sie die Verfahren von dieser Kategorie gemäß den folgenden Templates implementieren.
takeValuesFromDictionary: erzeugt hier seine eigene mutationsfähige Kopie des eingegangenen Verzeichnisses. Es handhabt die Schlüssel, welche es muß, wobei es sie vom Verzeichnis entfernt, so daß die Oberklassenimplementierung sie nicht auch setzen wird und leitet dann die verbleibenden Schlüsselwertpaare nach oben (to super). Um die Oberklassenimplementierung vollständig außer Kraft zu setzen, müßte dieses Verfahren jedes Schlüsselwertpaar im Verzeichnis handhaben und YES (JA) zurückgeben, falls alle Schlüsselwertpaare gehandhabt worden sind, und NO (NEIN), falls irgendeine von ihnen nicht abgearbeitet werden konnte.
valuesForKeys: erzeugt eine mutationsfähige Kopie der eingegangenen Schlüsselmatrix und ein mutationsfähiges Verzeichnis, in welcher die abgefragten Werte zu plazieren sind. Es handhabt die Schlüssel, welche es muß, und entfernt sie von der Matrix, reicht dann die verbleibenden Schlüssel nach oben und fügt die zurückgegebenen Werte dem Verzeichnis hinzu, welches es aufbaut. Um die Oberklassenimplementierung vollständig außer Kraft zu setzen, kann dieses Verfahren einfach die Nachricht nach oben auslassen, nachdem es alle Werte, welche es für die Schlüssel finden kann, in das Verzeichnis gelegt hat.

Warnungen

Drei Situationen verlangen Vorsicht bezüglich des Schlüsselwertkodierungsmechanismusses. Erstens, seien Sie sich bewußt, daß die Default- Implementierung von takeValuesFromDictionary: nicht die Reihenfolge garantiert, in welcher Eigenschaftswerte gesetzt werden. Somit sollten Ihre Unternehmensobjektszugriffsverfahren nicht annehmen, daß andere Eigenschaftswerte aufgestellt worden sind, wenn sie aufgerufen werden.
Zweitens, falls Ihre Anwendung die Zugriffsebene benutzt, sollten Sie vorsichtig sein beim Implementieren von Zugriffsverfahren, welche Werte setzen (oder beim Außerkraftsetzen von takeValuesFromDictionary:) über das Senden von Nachrichten zu den Wertobjekten im Verzeichnis. takeValuesFromDictionary: wird oft gesendet, während ein Abruf im Gange ist, und falls Ihre Implementierung eine Nachricht an ein EOFault-Objekt sendet, wird es versuchen, das Objekt, für welches es steht, abzurufen, wodurch es einen Serverfehler erzeugt. Siehe die informelle EODatabasechannelNotification- Protokollbeschreibung für Vorschläge, wie man sich um dieses Problem herumarbeiten kann.
Drittens ist es für einen Eigenschaftswert in einer Datenbank möglich, NULL zu sein, wobei in diesem Fall Ihr Unternehmensobjekt ein EONuII-Objekt als den Wert empfängt. Falls Sie NULL-Werte in Ihrer Datenbank erlauben, müssen Ihre Unternehmensobjekte überprüfen, ob die Werte, welche Sie empfangen, EONulls sind und sie geeignet behandeln.

Verfahrenstypen

Setzen und Erhalten von Werten - takeValuesFromDictionary:
- valuesFor Keys:
Rücksetzen von Schlüsselbindungen - flushKeyBindings

Instanzverfahren

flushKeyBindings

- (void)flushKeyßindings
Annuliert die zwischengespeicherte Schlüsselbindungsinformation für die Empfängerklasse. Das Enterprise Objects Framework benutzt diese Information, um die Default-Implementierungen der anderen Verfahren dieses Protokolls zu optimieren, indem es Verfahrens-Selektoren und Instanzvariablen-Typ-Information zwischenspeichert. Dieses Verfahren sollte aufgerufen werden, wann immer eine Klasse verändert oder von dem Laufzeitsystem entfernt wird.

takeValuesFromDictionary:

- (BOOL)takeValuesFromDictionary:(NSDictionary *)aDictionary
Setzt Eigenschaften des Empfängers mit Werten von aDictionary. Gibt YES zurück, falls der Empfänger alle Werte vom Verzeichnis gelesen hat, NO, falls er nicht alle Werte entnehmen konnte.
Beachten Sie: Die Zugriffs- und Schnittstellenebenen des Enterprise Objects Framework betrachten einen Rückgabewert von NO nicht als einen Fehler und ergreifen keine spezielle Maßnahme basierend auf einen solchen Rückgabewert.

valuesForKeys:

-(NSDictionary *) valuesForKeys:(NSArray *)keyArray
Gibt ein Verzeichnis zurück und stellt dabei so viele Werte wie möglich für die Schlüssel in keyArray bereit. Nicht alle abgefragten Werte werden garantiert ausgelesen.

Klassenbeschreibung

Ein EOFault ist ein Unternehmensobjekt (oder eine Matrix eines Unternehmensobjektes), deren Daten noch nicht von der Datenbank abgerufen worden sind. Wenn ein EODatabaseChannel (EODatenbankKanal) ein Objekt abruft, welches Relationen aufweist, erzeugt es EOFaults für die Ziele von solchen Relationen (wenn nicht, für zu- Eins (to-one)-Relationen, die entsprechenden Objekte schon abgerufen und vereinheitlicht worden sind). Dadurch, daß der EODatabaseChannel ein Objekt nicht abruft, bevor die Anwendung es tatsächlich benötigt, verhindert dieser eine unnötige Wechselwirkung mit dem Datenbankserver.
Ein EOFault kann ein Objekt darstellen, wobei es in diesem Fall als single-object fault (Einzelobjektfehler) bezeichnet wird, oder es kann eine Matrix von Objekten darstellen, welche durch einen Unterscheider (qualifier) beschrieben sind, wobei es in diesem Fall als array fault (Matrixfehler) bezeichnet wird. Zu-Eins Relationen führen zu single-object faults, während zu-viele (to-many)-Relationen zu array faults führen. Ein single-object fault ruft das reale Objekt auf und lädt dieses über sich selbst das erste Mal, wenn Sie eine Nachricht an es senden (mit einigen, unten aufgelisteten Ausnahmen). Ein array fault lädt seine Objekte, sobald Sie ihm irgendeine Nachricht schicken, welche ein Zugreifen auf den Inhalt der Matrix erfordert (objectAtIndex:, count, usw.). EOFaults von beiden Typen werden als fault objects (Fehlerobjekte) bezeichnet.
Das objectFaultWithPrimaryKey:entity:databaseChannel:zone:class-Verfahren erzeugt einen single-object fault und das arrayFaultWithQualifier:fetchOrder:databaseChannel:- zone:class-Verfahren erzeugt einen array fault. Mit alloc- und init-Nachrichten kann man kein fault object erzeugen.
Ihre Anwendung kann explizit fault objects erzeugen, um Abrufkonflikte zu vermeiden. Dies ist ein Anliegen für neu erzeugte Unternehmensobjekte, welche Objekte abrufen müssen - andere als solche, welche durch ihre Relationen gegeben sind - in ihren takeValuesFromDictionary:- oder awakeForDatabaseChannel:-Verfahren (beschrieben in den EOKeyValueCoding- bzw. EODatabaseChannelNotification-Protokollbeschreibungen). Da der Kanal, welcher das Unternehmensobjekt abgerufen hat, belegt ist, kann ihn das Unternehmensobjekt nicht benutzen, um andere Objekte abzurufen - und muß Sorge tragen, nicht auf irgendwelche Objekte zuzugreifen, welche im Augenblick fault objects sind. Ein Unternehmensobjekt kann einen verschiedenen Kanal benutzen, um ein anderes Objekt sofort abzurufen, oder es kann ein fault object erzeugen, so daß die Instanzvariable zumindest einen gültigen Zeiger (pointer) enthält.
Ein neu erzeugtes Unternehmensobjekt darf nicht auf ein fault object zugreifen, während sein Kanal mit Abrufen belegt ist. Dies zu tun, bewirkt, daß der fault einen Abruf mit jenem Kanal versucht, was zu einem Abrufkonflikt führt. Das Unternehmensobjekt kann auch nicht ein single-object fault durch ein Objekt ersetzen, welches es selbst abruft; der fault ist bereits vereinheitlicht worden, wenn das Unternehmensobjekt es erhält und andere Unternehmensobjekte können Verweise (references) auf ihn halten. Ein array fault kann jedoch ersetzt werden; Sie könnten einen array fault ersetzen wollen, um den Unterscheider zu ändern oder die Abrufordnung, welche verwendet wird, um seine Ziele abzurufen.

Nachrichten, welche kein Abrufen verursachen

Ein fault object antwortet auf einige Nachrichten, als ob es das Zielobjekt wäre, ohne einen Abruf zu verursachen. Zum Beispiel gibt class (Klasse) die Klasse des Objekts zurück, welches abgerufen werden wird, nicht die EOFault-Klasse. Die nachfolgenden Instanzverfahren verursachen weder, daß ein fault object abruft, noch verraten sie die wahre Identität eines fault objects:
autorelease
class
conformsToProtocol:
description
isKindOfClass:
isMemberOfClass:
isProxy (gibt NO zurück)
printForDebugger:
release
respondsToSelector:
retain
retainCount
zone

Zwingen eines Fault Objects zum Abruf

Sie können ein fault object zwingen, abzurufen, indem Sie ihm eine Nachricht senden, welche es nicht als ein fault handhaben kann. Die Nachrichten, welche in dem vorhergehenden Abschnitt aufgelistet sind, arbeiten alle mit generischer Laufzeitinformation und verursachen so kein Abrufen, aber jegliche Nachricht, welche auf Daten zugreift (wie etwa das Schlüsselwertkodierungsverfahren valuesForKeys: oder eine benutzerspezifische Nachricht wie etwa lastName), verursacht, daß der fault seine Daten mit seinem Datenbankkanal abruft. EOFault definiert auch die self (selbst)-Nachricht, so daß es immer den fault veranlaßt, abzurufen; dies stellt Ihnen ein Verfahren bereit, welches keine Auswirkung auf ein normales Objekt hat, aber welches Sie immer benutzen können, um ein fault object zu veranlassen, abzurufen. Behalten Sie in Erinnerung, daß Sie einen fault nicht veranlassen sollten, sich selbst abzurufen, falls sein Datenbankkanal belegt ist.
Mit einem single-object fault können Sie bequem ein refetchObject:-Verfahren von EODatabaseChannel benutzen, um die Daten für den fault zu erhalten. Diese Technik ermöglicht Ihnen, die Daten des faults abzurufen, sogar wenn sein Datenbankkanal belegt ist, und zwar durch Benutzen eines verschiedenen Datenbankkanals. refetchObject: überprüft, ob es für ein fault object abruft und wandelt den fault in eine Instanz seiner Unternehmensobjektklasse um.
Einem array fault einen Abruf aufzuzwingen wird am besten getan, indem der array fault durch einen ersetzt wird, welcher einen verschiedenen Datenbankkanal aufweist und man dann den neuen fault veranlaßt, sich selbst aufzurufen:
Dieser Codeauszug erzeugt einen neuen array fault mit der gleichen Information wie derjenige, welcher abgerufen wird, außer daß er einen Datenbankkanal benutzt, welcher nicht mit Abrufen belegt ist. Er sendet dann self an den neuen fault, um ihn zum Abrufen zu zwingen, und weist ihn der Originalvariable zu.

Instanzvariablen

Class iss;
iss Ein Zeiger auf die Klassenstruktur der Instanz.

Verfahrenstypen

Erzeugen eines fault + arrayFaultWithQualifier:fetchOrder:
databasechannel:zone:
+ objectFaultWithPrimaryKey:entity:
databaseChannel:zone:
Erhalten von Information über ein fault
+ clearFault:
+ databaseChannelForFault:
+ entityForFault:
+ fetchOrderForFault:
+ isFault:
+ primaryKeyForFault:
+ qualifierForFault:
+ targetClassForFault:
Spezielle Instanzverfahren - description
- self

Klassenverfahren

arrayFaultWithOualifier:fetchOrder:databaseChannel:zone:
+ (NSArray *)arrayFaultWithQualifier:(EOQualifier *)aQualifier
fetchOrder:(NSArray *)aFetchOrder
databaseChannel:(EODatabaseChannel *)aChannel
zone:(NSZone *)zone
Gibt einen array fault zurück, welcher aChannel seine Objekte gemäß aQualifier und aFetchOrder (eine Matrix von EOAttributeOrdering-Objekten) abrufen lassen wird, wenn zum ersten Mal auf ihn zugegriffen wird. Falls aChannel abruft, wenn auf die Matrix zugegriffen wird, wird ein Abrufskonflikt mit undefinierten Ergebnissen verursacht.
Siehe auch: + objectFaultWithPrimaryKey:entity:databaseChannel:zone

clearFault:

+ (void)clearFault:aFault
Wandelt aFault in eine neu initialisierte Instanz der Target-Klasse um. Ruft keine Daten für die neue Instanz ab. Erhebt NSInvalidArgumentException, falls es mit einem Objekt aufgerufen wird, welches kein fault object ist. Sie sollten dieses Verfahren selten nutzen müssen.
Siehe auch: + targetClassForFault:

databaseChannelForFault:

+ (EODatabaseChannel *)databaseChannelForFault:aFault
Gibt den EODatabaseChannel zurück, mit welchem aFault erzeugt wurde, oder Null (nil), falls aFault kein fault object ist.

entityForFault:

+ (EOEntity *)entityForFault:aFault
Gibt die Entität zurück, mit welcher aFault erzeugt wurde (oder wie durch den Unterscheider für ein array fault bestimmt). Gibt Null zurück, falls aFault kein fault object ist.

fetchOrderForFault:

+ (NSArray *)fetchOrderForFault:aFault
Gibt die Matrix von EOAttributeOrdering-Objekten zurück, mit welchen aFault erzeugt wurde, oder Null, falls aFault kein array fault ist.

isFault:

+ (BOOL)isFault:anabject
Gibt YES zurück, falls anObject ein fault object ist, andernfalls NO. Sie sollten dieses Verfahren verwenden, nicht isKindOfClass:, falls Sie wissen müssen, ob ein Objekt tatsächlich ein fault object ist.

objectFaultWithPrimaryKey:entity:databaseChannel:zone:

+ objectFaultWithPrimaryKey:(NSDictionary *)aKey
entity:(EOEntity *)anEntity
databaseChannel:(EODatabaseChannel *)aChannel
zone:(NSZone *)zöne
Gibt ein single-object fault für ein Unternehmensobjekt mit dem spezifischen Primärschlüssel und -entität zurück. Wenn darauf zugegriffen wird, ruft aChannel das aktuelle Objekt für den fault ab, wobei es es von zone zuweist. Falls aChannel gerade abruft, wenn der fault versucht, abzurufen, wird dies zu einem Abrufkonflikt mit undefinierten Ergebnissen führen.
Siehe auch: + arrayFaultWithQualifier:fetchOrder:databasechannel:zone

primaryKeyForFault:

+ (NSDictionary *)primaryKeyForFault:aFault
Gibt den Primärschlüssel für ein single-object fault zurück, Null für ein array fault oder nicht-fault object.

qualifierForFault:

+ (EOQualifier *)qualifierForFault:aFault
Gibt den Unterscheider zurück, welcher benutzt wird, um das Objekt oder Objekte, für welche aFault erzeugt wurde, abzurufen. Für ein single-object fault ist dies der Unterscheider der Entität, mit welcher der fault erzeugt wurde, plus die Primärschlüsselbeschreibung; für ein array fault ist dies einfach der Unterscheider, mit welchem der fault erzeugt wurde. Gibt Null zurück, falls fault kein aFault-Objekt ist.
Siehe auch: - qualifier(EOEntity)

targetClassForFault:

+ (Class)targetClassForFault:aFault
Gibt die Klasse zurück, welche instanzüert (instantiated) wird, wenn aFault abgerufen wird. Für ein single-object fault wird die Klasse durch die Entität bestimmt, mit welcher der fault erzeugt wurde; für ein array fault ist die Klasse NSMutableArray. Gibt Null zurück, falls aFault kein fault object ist.
Siehe auch: - entity (EOQualifier)

Instanzverfahren

description

- (NSString *)description
Gibt ein String-Objekt zurück, welches den Inhalt des fault object darstellt, ohne es zu veranlassen, seine Daten abzurufen. Eine Beschreibung des single-object fault enthält den Namen seiner Entität und den Wert seines Primärschlüssels; eine Beschreibung des array fault enthält den Unterscheider, welcher verwendet wird, um seine Objekte abzurufen.

self

- self
Veranlaßt das fault object, seine Daten abzurufen und self zurückzugeben. Sie können diese Nachricht verwenden, um ein fault object zu zwingen, seine Daten sofort abzurufen.

Klassenbeschreibung

Ein EOController synchronisiert einen Satz von datentragenden Unternehmensobjekten mit Benutzerschnittstellenobjekten; die Schnittstellenobjekte zeigen Werte für Eigenschaften der Unternehmensobjekte an und die Steuerung verarbeitet Änderungen an jenen Werten von den Schnittstellenobjekten. Die Objekte, welche ein EOController verwaltet, werden von einem data source-Objekt empfangen. Eine Datenquelle (data source) ist jegliches Objekt, welches sich an das EODataSources-Protokoll anpaßt, welches Verfahren zum Abrufen von Objekten vom Speicher, Einfügen von Objekten in den Speicher und Löschen von ihnen daraus und zum Ändern der Eigenschaften von existierenden Objekten definiert. Eine Datenquelle kann sich auch an die EOMasterDataSources- und EOQualifiableDataSources-Protokolle anpassen, wodurch es ihm ermöglicht ist, in Master-Detailrelationen (master-detail relationships) zu partizipieren, und an das EORollbackDataSources-Protokoll, wodurch es ihm ermöglicht ist, Änderungen zurückzusetzen.
Das Enterprise Object Framework stellt zwei Datenquellenklassen bereit: EODatabaseDataSource und EODetailDatabaseDataSource. Diese Klassen stellen Objekte für eine einzelne Entität in dem Anwendungsmodell bereit und passen sich auch den EOMasterDataSources-, EOQualifiableDataSources- und EORollbackDataSources- Protokollen an.
EOController stellt seine Unternehmensobjekte als ein NSArray (NSMatrix) dar, und identifiziert sie allein durch einen Index in dieser Matrix. Ein EOController behält auch eine Auswahl in der Form eines Satzes von Indexen bei. Sie können ein Objekt an einem bestimmten Index einfügen, löschen oder aktualisieren oder können eine Operation auf alle ausgewählten Objekte anwenden.

Assoziierungen

Ein EOController kommuniziert mit Benutzerschnittstellenobjekten durch EOAssociation- Objekte. Eine Assoziierung verbindet eine einzelne, benannte Eigenschaft des Steuerungsunternehmensobjekts mit einem Benutzerschnittstellenobjekt, wie etwa einem TextField (TextFeld) oder NXTableView (NXTabellenAnsicht). Die Assoziierung ist für die Überwachung des Benutzerschnittstellenobjekts verantwortlich, und benachrichtigt die Steuerung, wenn sich die Auswahl verändert oder wenn das Benutzerschnittstellenobjekt editiert wird, und aktualisiert das Benutzerschnittstellenobjekt, um die Werte der Steuerungsunternehmensobjekte wiederzugeben.
Sie können die meisten Assoziierungen im Interface Builder (Schnittstellen-Aufbauer) erzeugen, aber falls Sie eine durch Programmierung aufstellen müssen, können Sie normalerweise diesem Template folgen:
Dieser Code-Auszug geht von keiner Kenntnis über Assozüerungsunterklassen aus; er sendet associationClass an das Benutzerschnittstellenobjekt, um eine Default-Klasse für Assoziierungen zu erhalten, erzeugt dann die Assoziierung, um die als "propertyName" (EigenschafisName) benannte Eigenschaft zu überwachen. (Möglicherweise möchten Sie bestätigen, daß das Benutzerschnittstellenobjekt auf associationClass antwortet, bevor Sie es senden). Schließlich fügt es die Assoziierung dem Satz hinzu, welcher durch die Steuerung mit addAssociation: verwaltet wird.
Beachten Sie: Dieser Ansatz funktioniert nicht für ein NXTableView. Seine Assoziierungsklasse, EOColumsAssociation, erfordert eine spezielle Handhabung. Siehe die EOColumnAssociation-Klassenbeschreibung für mehr Information.
Falls Sie eine spezielle Assoziierungsklasse haben, welche dazu entworfen ist, um mit einem Benutzerschnittstellenobjekt zu arbeiten, können Sie explizit eine Instanz jener Klasse erzeugen, anstatt das Benutzerschnittstellenobjekt nach seiner Default- Assoziierungsklasse zu fragen. associationClass ist einfach ein Mechanismus, um dynamisch eine geeignete Assoziierung für ein vorgegebenes Benutzerschnittstellenobjekt auszuwählen.
Eine Assoziierung bildet eine enge Verbindung mit ihrem Benutzerschnittstellenobjekt. Sie stellt sich fast immer als ein Steuerungs-Target auf und stellt sich auch oft als die Textanordnung (text delegate) ihres Benutzerschnittstellenobjekts auf. Sie sollten annehmen, daß ein Benutzerschnittstellenobjekt, welches durch eine Assoziierung verwaltet wird, off-limits bezüglich Ändern seines Zustands ist und alle Datenmanipulation und -validierung in der Steuerungsanordnung oder in den Unternehmensobjekten selbst handhaben (beachten Sie, daß eine benutzerspezifische Assoziierung auch eine Validierung handhaben kann).
Ein geringfügig verschiedener Assoziierungstyp ist jener zwischen zwei EOControllern. Eine EOQualifiedAssociation verbindet zwei Steuerungen in einer Master-Detailrelation, so daß, wenn das in der Master-Steuerung ausgewählte Objekt sich ändert, die Datenquelle der Detail-Steuerung konfiguriert wird, um Objekte bereitzustellen, welche auf dasjenige bezogen sind, welches in dem Master ausgewählt ist.

Master-Detail-Steuerungen (Master-detail Controllers) und die Steuerungskette

(Controller Chain)

Steuerungen, welche in einer Master-Detailrelation verbunden sind, werden speziell behandelt. Wenn ein EOController eine Abruf-, saveToObjects-, saveToDataSource- oder redisplay-Nachricht durchführt, überprüft es das Ziel von jeder seiner Assoziierungen, um zu sehen, ob jenes Objekt auch ein EOController ist. Falls dies so ist, gibt es die Operation an sie bekannt und synchronisiert somit den Zustand und die Anzeige von allen verbundenen Steuerungen.
Falls Sie kein Steuerungspaar in einer Master-Detailrelation aufstellen wollen, können Sie immer noch eine von ihnen die oben gelisteten Verfahren bekannt geben lassen, indem Sie die setNextController:-Nachricht verwenden oder die zwei Steuerungen im Interface Builder verbinden. Das Miteinander-Verbinden von Steuerungen in dieser Weise ermöglicht den andernfalls unabhängigen Steuerungen, wobei jede ihren eigenen Satz von Unternehmensobjekten verwaltet, bezüglich allen bedeutsamen Operationen synchronisiert zu bleiben. Sie können jegliche Anzahl von Steuerungen in dieser Gestalt miteinander verbinden, aber Sie sollten sich bewußt sein, daß die vier Aktionen nur die Kette runterwärts bekannt gegeben werden; Steuerungen überhalb derjenigen, welche die Originalnachricht empfängt, werden nicht benachrichtigt (außer die Kette ist eine Schleife, welche zugelassen ist).

Pufferung und Undo (Rückgängigmachung)

EOController bietet zwei Änderungspufferungsebenen und einen wirkungsvollen Rückgängigmachungsmechanismus. Es gibt zwei Arten von Änderungen: edits (Editierungen) der Werte von Unternehmensobjekten und operations (Operationen) an den Unternehmensobjekten in der Datenquelle (Einfügung, Löschung und Aktualisierung mit gepufferten Editierungen). Wenn eine Steuerung Editierungen puffert, sichert sie jede Änderung, welche durch ihre Assoziierungsobjekte gesendet werden. Es wendet diese Änderungen nicht auf seine Unternehmensobjekte an, bevor es eine saveToObjects- Nachricht erhalten hat. Gleichermaßen werden Operationen an den durch die Steuerung gehaltenen Objekten nicht auf die Datenquelle angewandt, bevor die Steuerung eine saveToDataSource-Nachricht empfangen hat.
Sie können eine Pufferung entfernen, so daß Änderungen sofort gesichert werden, indem Sie einer Steuerung eine setSavesToObjectsAutomatically:- oder setSavesToDataSourceAutomatically:-Nachricht senden. Diese Tabelle zeigt, wie automatisches Sichern den Zustand der Unternehmensobjekte und der Datenquelle der Steuerung beeinflußt:
Sichert automatisch zu:
Zusätzlich zu Pufferungsänderungen, behält ein EOController einen Undo-Stapel bei, welcher jene Änderungen aufnimmt, nachdem sie angewendet worden sind. Sie können einer Steuerung eine markUndo-Nachricht jederzeit senden, um den aktuellen Punkt auf dem Undo-Stapel zu markieren. Eine spätere Undo-Nachricht setzt die Änderungen in dem Undo-Stapel zurück zu jenem Punkt: Gelöschte Objekte werden wiederhergestellt, eingefügte Objekte werden gelöscht und alle Editierungen - schwebend und gesichert - werden rückgängig gemacht. Sie können einen EOController dazu konfigurieren, daß er automatisch einen Undo-Punkt nach jeder Operation markiert oder Sie können Undo-Markierungen manuell steuern, um Operationen zusammen zu gruppieren, so daß alle mit einer einzelnen Undo-Nachricht rückgängig gemacht werden können.
Für mehr Information zu Datenquellen, siehe die EODataSources- und EOQualifiableDataSources-Protokollbeschreibungen.

Benachrichtigen der Steuerungsanordnung

Ein EOController benachrichtigt seine Anordnung über nahezu jede Operation, welche er durchführt. Er bestätigt jegliche Einfügung, Löschung oder Aktualisierung mit seiner Anordnung, bevor er die Operation durchführt, und benachrichtigt die Anordnung von Undo- und Sicherungsoperationen und von jeglicher Auswahlsänderung. Ferner, falls eine Änderung an der Datenquelle aus irgendeinem Grund fehlschlägt, hat die Anordnung die Möglichkeit, der Steuerung mitzuteilen, ob einfach fortzufahren ist oder Änderungen rückzusetzen sind (falls die Datenquelle Rücksetzen unterstützt).
Alles, was eine Anordnung tun muß, um eine Benachrichtigung von ihrer Steuerung zu empfangen, ist, die geeigneten Verfahren zu implementieren. Diese Verfahren sind nach EOControllers Klassen- und Instanzverfahren dokumentiert, unter "Verfahren, welche durch die Anordnung implementiert sind". Falls die Anordnung ein bestimmtes Verfahren nicht implementiert, wird es nicht aufgerufen.

Instanzvariablen

Keine in dieser Klasse deklariert.

Verfahrenstypen

Initialisieren eines EOControllers - initWithDataSource:
Verwalten von Assoziierungen - addAssociation:
- associations
- keys
- removeAssociation:
Erhalten der Objekte - allObjects
Abrufen von Objekten - fetch
Verwalten der Auswahl - setSelectionindexes:
- selectionindexes
- selectedObjects
- clearSelection
- selectNext
- selectPrevious
- setSelectsFirstObjectsAfterFetch:
selectsFirstObjectAfterFetch
Editieren von Objekten - associationDidEdit:
- setValues:forObject:
- endEditing
Durchführen von Operationen an Objekten
- deleteObjectAtIndex:
- deleteSelection
- insertObjectAtIndex:
- insertObject:AtIndex:
Verwerfen von Änderungen - discardEdits
- discardOperations
- isDiscardAllowed
Sichern von Editierungen zu Objekten - saveToObjects
- hasChangesForObjects
- setSavesToObjectsAutomatically:
- savesToObjectsAutomatically
Sichern zu der Datenquelle - saveToDataSource
- hasChangesForDataSource
- setSavesToDataSourceAutomatically:
- savesToDataSourceAutomatically
Steuerung von Undo - setUndoEnabled:
- isUndoEnabled
- markUndo
- undo
- releaseUndos
- setMarksEveryOperation:
- marksEveryOperation
- setMaximumUndoMarks:
- maximumUndoMarks
Wiederdarstellen der Benutzerschnittstelle - redisplay
Verketten von Steuerungen - setNextController:
- nextController
Setzen der Datenquelle - setDataSource
- dataSource
Setzen der Anordnung - setoelegate:
- delegate
Aktionsverfahren - delete:
- discardEdits:
- discardoperations:
- fetch:
- insert:
- markUndo:
- saveToDataSource:
- saveToObjects:
- selectNext:
- selectPrevious:
- undo:

Instanzverfahren

addAssociation:
- (void)addAssociation:(EOAssociation *)anAssociation
Fügt dem durch die Steuerung verwalteten Satz anAssociation hinzu.
Siehe auch: - removeAssociation:, - associations

allObjects

- (NSArray *)allObjects
Gibt alle Unternehmensobjekte zurück, welche durch die Steuerung zugänglich sind.
Siehe auch: - selectedabjects

associationDidEdit:

(void)associationDidEdit:(EOAssociation *)anAssociation
Informiert die Steuerung, daß anAssociation eine schwebende Editierung aufweist. Die Steuerung erhält Schlüssel und Wert von anAssociation und fügt den neuen Wert ihrem Editierungspuffer hinzu.
Falls die Steuerung konfiguriert ist, um Änderungen automatisch zu sichern, dann werden die Änderungen sofort zu den Objekten gesichert. Falls die Steuerung die Änderungen nicht automatisch sichert, treten die Änderungen nicht in Wirkung, bevor die Steuerung eine saveToObjects-Nachricht empfängt.
Dieses Verfahren ruft das Anordnungsverfahren controller:association:didEdit- Object:key:value: auf.
Siehe auch: - key (EOAssociation), - value(EOAssociation), - savesToObjects- Automatically, - savesToDataSourceAutomatically

associations

(NSArray *)associations
Gibt die Assoziierungen der Steuerung zurück.

clearSelection

- (BOOL)clearSelection
Leert die Auswahl der Steuerung. Dieses Verfahren ist ein Kürzel, um netSelection: mit einer leeren Matrix zu senden. Es macht keine Wiederdarstellung des Benutzerschnittstellenobjekts. Gibt YES zurück, falls erfolgreich, NO, falls nicht.
Siehe auch: - redisplay

dataSource

- (id < EODataSources> )dataSource
Gibt die Datenquelle der Steuerung zurück.

delegate

- delegate
Gibt die Anordnung der Steuerung zurück.

delete:

- delete:sender
Dieses Aktionsverfahren ruft deleteSelection auf, um alle ausgewählten Objekte zu löschen. Gibt self zurück, falls deleteSelection YES zurückgibt, Null, falls es NO zurückgibt.

deleteObjectAtIndex:

- (BOOL)deleteObjectAtIndex:(unsigned int)anIndex
Löscht das Objekt bei anIndex, schwebende Zustimmung durch die Anordnung. Gibt YES zurück, falls das Objekt tatsächlich gelöscht wird. Andernfalls NO.
Falls die Datenquelle nicht löschen kann, öffnet dieses Verfahren ein Abruffeld, welches den Benutzer benachrichtigt und NO zurückgibt. Falls die Datenquelle löschen kann, ruft es endEditing auf und benachrichtigt die Anordnung mit controller:willDelete:Object. Falls die Anordnung zustimmt, löscht es das Objekt und benachrichtigt die Anordnung mit controller:didDeleteabject: und die Assoziierungen der Steuerung mit contentsDidChange und selectionDidChange.
Löschung ist eine Operation, welche sofort auf das Objekt angewendet wird; Sie müssen nicht saveToObjects senden. Falls die Steuerung konfiguriert ist, um automatisch zu der Datenquelle zu sichern, dann werden die Änderungen sofort auch ah der Datenquelle vorgenommen. Falls die Steuerung Änderungen nicht automatisch sichert, treten die Änderungen nicht in der Datenquelle nicht in Wirkung, bevor die Steuerung eine saveToDataSource-Nachricht empfängt.
Siehe auch: - delete:, - deleteSelection, - savesToDataSourceAutomatically

deleteSelection

- (BOOL)deleteSelection
Löscht alle Objekte in der Auswahl und zwar in der für deleteObjectAtIndex: beschriebenen Weise (einschließlich Aufruf von Anordnungsverfahren). Gibt YES zurück, falls alle Objekte in der Auswahl erfolgreich gelöscht wurden (oder falls dort keine Objekte ausgewählt wurden). Andernfalls NO. Falls dieses Verfahren NO zurückgibt, ist es möglich, daß nur ein paar Objekte in der Auswahl gelöscht worden sind:
Löschen der Auswahl wird als eine Einzeloperation für Undo-Zwecke betrachtet, sogar wenn die Steuerung jede Operation markiert.
Siehe auch: - delete:

discardEdits

- (void)discardEdits
Löscht alle Editierungen, welche in der Steuerung und auch in Benutzerschnittstellenobjekten im schwebenden Zustand sind (durch Senden von discardEdits an alle Assoziierungen der Steuerung). Dieses Verfahren ist nur nützlich, falls die Steuerung nicht dazu konfiguriert ist, Objekte automatisch zu sichern.
Siehe auch: - savesToObjectsAutomatically

discardEdits:

- discardEditsaender
Diese Aktionsverfahren ruft discardEdits auf und gibt self zurück.

discardOperations

(void)discardOperations
Löscht alle schwebenden Operationen. Dieses Verfahren ist nur nützlich, falls die Steuerung nicht dazu konfiguriert ist, automatisch zu der Datenquelle zu sichern.
Siehe auch: - savesToDataSourceAutomatically

discardOperations:

- discardQperations:sender
Dieses Aktionsverfahren ruft discardOperations auf und gibt self zurück.

endEditing

- (void)endEditing
Sendet endEditing an jede der Assoziierungen der Steuerung. Dieses Verfahren wird aufgerufen, wann immer die Steuerung ein Ende der Editierung in den Benutzerschnittstellenobjekten erzwingen muß, was immer der Fall ist, wenn:
- Die Steuerung abruft.
- Die Steuerung Änderungen zu ihren Objekten oder zu ihrer Datenquelle sichert.
- Ein Objekt eingefügt oder gelöscht wird.
- Die Auswahl sich ändert.
- Der Undo-Stapel durch eine markUndo-, undo- oder releaseUndos-Nachricht geändert wird.
Siehe auch: - endEditing (EOAssociationNotification-Protokoll)

fetch

- (BOOL)fetch
Ruft Objekte von der Datenquelle der Steuerung ab, gibt YES zurück, falls erfolgreich, NO, falls nicht.
Ruft endEditing vor dem Abrufen auf und bestätigt, daß schwebende Änderungen verworfen werden können, indem isDiscardAllowed aufgerufen wird. Bestätigt auch, daß jegliche Detail-Steuerungen schwebende Änderungen verwerfen können, Bricht den Abruf ab und gibt NO zurück, falls isDiscardAllowed NO zurückgibt oder falls jegliche der Detail- oder verbundenen Steuerungen ein Verwerfen nicht ermöglichen.
Nach Bestätigen, daß Änderungen verworfen werden können, fährt es fort, alle Editierungen und Operationen zu verwerfen und löscht den Undo-Stapel. An diesem Punkt sendet die Steuerung controllerWillFetch: an seine Anordnung, wobei der Abruf abgebrochen und NO zurückgegeben wird, falls die Anordnung NO zurückgibt. Falls die Anordnung YES zurückgibt, sendet die Steuerung fetchObjects an seine Datenquelle und resynchronisiert seine Auswahl mit den neuen Objekten.
Nach Abrufen von Objekten sendet die Steuerung controllerDidFetchObjects: an seine Anordnung und contentsDidChange an seine Assoziierungen. Falls die Auswahl der Steuerung sich als eine Folge des Abrufens geändert hat, sendet sie auch selectionDidChange an die Assoziierungen. Schließlich gibt die Steuerung die Abrufnachricht an alle Detail- und verbundenen Steuerungen bekannt.
Siehe auch: - discardEdits, - releaseUndos, - selectsFirstObjectAfterFetch

fetch:

- fetch:sender
Dieses Aktionsverfahren ruft fetch auf und gibt self zurück, falls fetch YES zurückgibt, Null, falls es NO zurückgibt.

hasChangesForDataSource

- (BOOL)hasChangesForDataSource
Gibt YES zurück, falls es irgendwelche gepufferten Operationen für die Datenquelle gibt, andernfalls NO.
Siehe auch: - savesToDataSourceAutomatically, - hasChangesForObjects, - saveTo- Objects

hasChangesForObjects

- (BOOL)hasChangesForObjects
Gibt YES zurück, falls irgendein Objekt seit der letzten saveToObjects-Nachricht editiert worden ist, andernfalls NO.
Siehe auch: - savesToObjectsAutomatically, - hasChangesForDataSource,
- associationDidEdit, - setValues:forObject:

initWithDataSource:

- initWithDataSource:(id < EODataSources> )aDataSource
Initialisiert einen neu zugewiesenen EOController, um seine Daten von Objekten zu erhalten, welche durch aDataSource bereitgestellt sind. Dies ist der festgelegte Initialisierer für die EOController-Klasse. Gibt self zurück.

insert:

- insert:sender
Dieses Aktionsverfahren benutzt insertObjectAtIndex:, um ein neues Objekt nach dem ausgewählten Objekt einzufügen, oder, falls nichts ausgewählt ist, am Ende der Matrix. Gibt self zurück, oder Null, falls insertObjectAtIndex: Null zurückgibt.

insertObjectAtIndex:

- insertObjectAtIndex:(unsigned int)anIndex
Fügt ein neues Objekt, welches durch die Datenquelle der Steuerung erzeugt wurde, ein und wählt dieses aus, und zwar bei anIndex, indem insertObject:AtIndex: aufgerufen wird. Ruft endEditing auf, bevor es die Einfügung durchführt. Gibt das Objekt zurück, welches eingefügt wurde, oder Null bei Fehlschlagen.
Beachten Sie: Sie müssen den Primärschlüssel des neuen Objekts vor dem Sichern zu der Datenquelle setzen. Falls die Steuerung konfiguriert ist, um automatisch zu der Datenquelle zu sichern, sollten Sie dieses Verfahren nicht benutzen.
Erhebt NSRangeException, falls anIndex eine Position nach dem Ende der Objektematrix der Steuerung anzeigt.
Siehe auch: - createObject (EODataSources-Protokoll der Zugriffsebene)

insertObject:AtIndex:

insertObject:anEO AtIndex:(unsigned int)anIndex
Fügt anEO bei anIndex in der Unternehmensobjektematrix ein, welche durch die Steuerung verwaltet wird. Ruft endEditing auf, bevor es die Einfügung durchführt. Gibt das Objekt, welches eingefügt wurde, zurück, oder Null bei Fehlschlagen. Erhebt NSRangeException, falls anindex eine Position nach dem Ende der Objektematrix der Steuerung anzeigt.
Einfügung ist eine Operation, welche sofort auf das Objekt angewandt wird; Sie müssen saveToObjects nicht senden. Falls die Steuerung konfiguriert ist, um automatisch zu der Datenquelle zu sichern, dann werden die Änderungen auch sofort an der Datenquelle vorgenommen. Falls die Steuerung Änderungen nicht automatisch sichert, treten die Änderungen in der Datenquelle nicht in Wirkung, bevor die Steuerung eine saveToDataSource-Nachricht empfängt.
Beachten Sie: Sie müssen einen Primärschlüssel des anEO vor dem Sichern zu der Datenquelle setzen. Falls die Steuerung konfiguriert ist, um zu der Datenquelle zu sichern, muß anEO seinen Primärschlüssel bereits gesetzt haben, wenn Sie ihn einfügen.
Nach Einfügen des Objekts, wählt die Steuerung es aus und sendet contentsDidChange und selectionDidChange zu allen Ihren Assoziierungen.
Dieses Verfahren ruft das Anordnungsverfahren controller:willInsertObject, controller:didInsertObject, und controller:failedToInsertObject: auf. Siehe die Beschreibungen für diese Verfahren für Information darüber, wie Sie die Einfügung beeinflussen.
Siehe auch: - insert, - savesToDataSourceAutomatically

isDiscardAllowed

- (BOOL)isDiscardAllowed
Verifiziert, daß das Verwerfen von Editierungen, welche nicht zu Objekten gesichert wurden, und Aktualisierungen, welche nicht zu der Datenquelle gesichert wurden, ermöglicht ist. Gibt YES zurück, falls das Verwerfen von Editierungen und Aktualisierungen ermöglicht ist, NO, falls nicht. Eine Steuerung benutzt dieses Verfahren, wenn sie die Auswahl abruft und ändert, um sicherzustellen, daß eine Operation nicht versehentlich schwebende Veränderungen verwirft.
Falls die Steuerung irgendwelche schwebenden Editierungen aufweist, sendet es controllerWillDiscardEdits: an die Anordnung. Falls die Anordnung NO zurückgibt, gibt dieses Verfahren sofort NO zurück. Falls die Anordnung YES zurückgibt, fährt dieses Verfahren fort, indem es überprüft, ob Operationen verworfen werden können. Falls die Anordnung controllerWillDiscardEdits: nicht implementiert, öffnet die Steuerung ein Abruffeld, wobei sie den Benutzer fragt, ob es in Ordnung ist, Editierungen zu verwerfen. Das Feld eröffnet dem Benutzer die Wahl, die Editierungen zu sichern (was verursacht, daß saveToObjects aufgerufen wird), zu löschen, welche Operation auch immer dieses Verfahren aufgerufen hat, oder zu ermöglichen, daß Editierungen verworfen werden; falls der Benutzer wählt, Editierungen zu sichern oder zu löschen, gibt dieses Verfahren NO zurück.
Als nächstes, falls es irgendwelche Operationen gibt, welche nicht zu der Datenquelle gesichert sind, sendet die Steuerung controllerWillDiscardOperations: an die Anordnung. Wiederum, falls die Anordnung dieses Verfahren nicht implementiert, öffnet die Steuerung ein Abruffeld, welches den Benutzer fragt, Operationen zu sichern, zu löschen oder das Verwerfen von diesen zu ermöglichen; falls der Benutzer wählt, Operationen zu sichern oder zu löschen, gibt dieses Verfahren NO zurück. Schließlich, falls alle diese Bedingungen übergangen werden, gibt dieses Verfahren YES zurück.
Siehe auch: - discardEdits, - saveToObjects, - saveToDataSource

isUndoEnabled

- (BOOL)isUndoEnabled
Gibt YES zurück, falls undo ermöglicht ist, andernfalls NO. Undo ist bei Default- Einstellung für durch Programmierung erzeugte Steuerungen nicht ermöglicht, obwohl es dies für Steuerungen ist, welche im Interface Builder erzeugt wurden.

keys

- (NSArray *)keys
Gibt die Schlüssel zurück, welche durch die Steuerungsassoziierungen benutzt werden (welche nicht notwendigerweise alle die Schlüssel sind, welche durch ihre Unternehmensobjekte benutzt werden). Diese Schlüssel sind die Namen von Eigenschaften von den Steuerungsunternehmensobjekten, wie in dem informellen EOKeyValueCoding-Protokoll benutzt, welches durch die Zugriffsebene definiert ist. Es kann Duplikatschlüssel in der zurückgegebenen Matrix geben.
Siehe auch: - key(EOAssociation)

markUndo

- (void)markUndo.
Beendet das Editieren und markiert den aktuellen Zustand des Undo-Stapels als einen Undo-Punkt. Eine Undo-Nachricht setzt Änderungen zurück, welche seit dem letzten markierten Undo-Punkt gemacht worden sind. Dieses Verfahren tut nichts, falls undo nicht ermöglicht ist oder falls eine Markierung schon auf dem oberen Ende des Undo- Stapels gesetzt ist.
Siehe auch: - isUndoEnabled, - releaseUndos, - endEditing

markUndo:

- markUndo:sender
Dieses Aktionsverfahren ruft markUndo auf und gibt self zurück.

marksEveryOperation

- (BOOL)marksEveryOperation
Gibt YES zurück, falls ein Undo-Punkt auf jede Einfügung, Löschung und Anwendung von Editierungen an einem Unternehmensobjekt hin markiert wird, andernfalls NO. Steuerungen, welche durch Default-Programmierung erzeugt worden sind, markieren nicht jede Operation, während solche, welche im Interface Builder erzeugt worden sind, dies tun.
Siehe auch: - deleteSelection

maximumUndoMarks

- (unsigned int)maximumUndoMarks
Gibt die Maximalanzahl von Undo-Markierungen zurück, welche die Steuerung registrieren wird. Markierungen, welche über dieses Limit hinaus hinzugefügt werden, verursachen, daß frühere Markierungen aus der Schlange fallen. Dieses Verfahren ist nützlich, um die Speichernutzung zu beschränken. Das Default-Maximum ist Null, was tatsächlich kein Limit anzeigt.
Siehe auch: - isUndoEnabled

nextControtler

- (EOController *)nextController
Gibt die nächste Steuerung in der Steuerungskette zurück. Siehe die Klassenbeschreibung für Information über die Steuerungskette.

redisplay

- (void)redisplay
Sendet contentsDidChange an alle Steuerungsassoziierungen, was diese veranlaßt, ihre Benutzerschnittstellenelemente wiederdarzustellen, wie benötigt. Läßt auch die Steuerungs-Detail-Steuerungen und Folgesteuerung wiederdarstellen.
Siehe auch: - nextController

releaseUndos

- (void)releaseUndos
Löscht alle Undo-Information. Kein undo ist möglich, bis ein neuer Undo-Punkt errichtet wird, entweder automatisch oder mit markUndo.
Siehe auch: - marksEveryOperation

removeAssociation:

- (void)removeAssociation:(EOAssociation *)anAssociation Entfernt anAssociation von dem Satz, welcher durch die Steuerung verwaltet wird.
Siehe auch: - addAssociation:

savesToDataSourceAutomatically

- (BOOL)savesToDataSourceAutomatically
Gibt YES zurück, falls Sichern zu Objekten oder Einfügen oder Löschen eines Objekts dazu führt, daß die Steuerung saveToDataSource durchführt, NO, falls es dies nicht tut. Steuerungen, welche durch Default-Programmierung erzeugt wurden, sichern nicht automatisch, aber solche, welche im Interface Builder erzeugt wurden, tun dies.
Siehe auch: - saveToObjects, - savesToObjectsAutomatically

savesToObjectsAutomatically

- (BOOL)savesToObjectsAutomatically
Gibt YES zurück, falls die Steuerung sofort saveToObjects durchführt, wenn eine Assoziierung sie über eine Editierung benachrichtigt oder wenn ein Objekt mit setValues:forObject: editiert wird. Gibt andernfalls NO zurück. Steuerungen, welche durch Default-Programmierung erzeugt wurden, speichern nicht automatisch, aber solche, welche im Interface Builder erzeugt wurden, tun dies.
Siehe auch: - associationDidEdit, - savesToDataSourceAutomatically

saveToDataSource

- (BOOL)saveToDataSource
Beendet Editieren und sichert alle schwebenden Operationen für die Steuerung selbst, für ihre Detail-Steuerungen und für Ihre Folgesteuerung. Falls keine der Steuerungen Editierungen zu Ihren Objekten gesichert hat, hat dieses Verfahren keine Wirkung; benutzen Sie saveToObjects, um sicherzustellen, daß schwebende Editierungen auf die Objekte angewandt werden, bevor Sie saveToDataSource aufrufen. Gibt YES zurück, falls alle Änderungen erfolgreich zu der Datenquelle gesichert sind, NO, falls irgendeine Sicherungsoperation fehlgeschlagen ist oder durch die Anordnung zurückgewiesen wird. Falls dieses Verfahren NO zurückgibt und die Datenquelle der Steuerung Rücksetz-Operationen nicht unterstützt, können ein paar Änderungen trotzdem gesichert worden sein.
Im Sichern eines Objekts, sendet die Steuerung ihm eine prepareForDataSource- Nachricht (falls es antwortet). Falls das Objekt NO zurückgibt, sendet die Steuerung seiner Anordnung eine controller:object:failedToPrepareForDataSource:-Nachricht. Falls die Anordnung EOContinueDataSourcelFailureResponse zurückgibt, fährt die Steuerung damit fort, die verbleibenden Objekte zu sichern. Falls die Anordnung EORollbackDataSourceFailureResponse zurückgibt oder das Anordnungsverfahren nicht implementiert, setzt die Steuerung alle Operationen zurück - falls die Datenquelle ein Rücksetzen unterstützt - und gibt NO zurück.
Falls das Objekt YES von prepareForDataSource zurückgibt, dann überprüft die Steuerung mit seiner Anordnung jede zu sichernde Operation und sendet insertObject, deleteObject, oder updateObject: an die Datenquelle, abhängig von der zu sichernden Änderung. Falls irgendeine dieser Nachrichten fehlschlägt, informiert dieses Verfahren die Anordnung, hält das Sichern an und gibt NO zurück.
Dieses Verfahren kann jegliches der unten aufgelisteten Anordnungsverfahren aufrufen, abhängig von den einzelnen Sicherungsoperationen, welche durchgeführt werden. Siehe die Beschreibungen der einzelnen Verfahren für mehr Information darüber, wie Sie mit saveToDataSource wechselwirken.
controller:object:failedToPrepareForDataSource:
controllerWillSaveToDataSource:
controllerDidSaveToDataSource:
controller:willRollbackDataSource:
controller:didRollbackDataSource:
controller:willInsertObject:inDataSource:
controller:didInsertObject:inDataSource:
controller:failedToInsertObject:inDataSource:
controller:willDeleteObject:inDataSource:
controller:didDeleteObject:inDataSource:
controller:failedToDeleteObject:inDataSource:
controller:willUpdateObject:inDataSource:
controller:didUpdateObject:inDataSource:
controller:failedToUpdateObject:inDataSource:
Siehe auch: - insertObjectAtIndex:, - deleteObjectAtIndex:, - endEditing

saveToDataSource:

- saveToDataSource:sender
Dieses Aktionsverfahren ruft saveToDataSource auf, gibt self zurück, falls saveToDataSource YES zurückgibt, Null, falls es NO zurückgibt.

saveToObjects

- (BOOL)saveToObjects
Beendet Editieren und sichert alle an Objekten vorgenommenen Editierungen als Operationen zum Anwenden auf die Datenquelle der Steuerung. Gibt YES zurück, falls alle Änderungen erfolgreich zu den Steuerungsobjekten gesichert wurden, NO, falls irgendeine Sicherungsoperation fehlschlägt oder durch die Anordnung abgelehnt wird. Falls dieses Verfahren NO zurückgibt, können einige Änderungen gesichert worden sein, während andere dies nicht sind.
Beim Sichern eines Satzes von Editierungen zu einem Unternehmensobjekt, bestätigt die Steuerung zuerst ihrer Anordnung die Aktion, indem sie ihr eine controller:willSaveEdits:toObject:-Nachricht sendet; falls die Anordnung Null zurückgibt, bricht die Steuerung die Sicherungsoperation ab und gibt NO zurück. Die Steuerung nimmt einen Nicht-Null-Rückgabewert von dieser Nachricht und konvertiert den neuen Wert durch Senden von coerceValue:forkey: an ihre Datenquelle. Sie wendet dann die konvertierten Werte auf das Unternehmensobjekt an, indem sie dem Unternehmensobjekt eine takeValuesFromDictionary:-Nachricht sendet (ein Verfahren des informellen EOKeyValueCoding-Protokolls der Zugriffsebene). Nach Sichern von jedem Objekt sendet die Steuerung controller:didSaveToObject: an seine Anordnung.
Falls die Steuerung automatisch zu der Datenquelle sichert, dann wird jede gesicherte Editierung sofort auf die Datenquelle angewendet. Falls die Steuerung Änderungen nicht automatisch sichert, beeinflussen die Änderungen die Datenquelle nicht, bevor die Steuerung eine saveToDataSource-Nachricht empfängt.
Schließlich, nach Sichern aller Editierungen, sendet die Steuerung contentsDidChange und discardEdits an seine Assoziierungen. Falls alle der Änderungen erfolgreich gesichert wurden, läßt die Steuerung ihre Detail-Steuerungen und Folgesteuerung auch zu Objekten sichern.
Siehe auch: - associationDidEdit, - setValues:forObject, - saveToDataSource,
- endEditing

saveToObjects:

- saveToObjects:sender
Dieses Aktionsverfahren ruft saveToObjects auf, gibt self zurück, falls saveToObjects YES zurückgibt, Null, falls es NO zurückgibt.

selectNext

- (BOOL)selectNext
Wählt das Objekt nach dem aktuell ausgewählten Objekt aus. Falls keine Objekte ausgewählt sind oder falls das letzte Objekt ausgewählt ist, dann wird das erste Objekt ausgewählt. Falls Mehrfachobjekte ausgewählt sind, wählt dieses Verfahren das Objekt nach dem ersten Objekt in der Auswahl aus. Dieses Verfahren führt dazu, daß eine setSelectionindexes:-Nachricht gesendet wird, uhd gibt den Wert zurück, welcher durch jene Nachricht zurückgegeben wird.
Dieses Verfahren ist nützlich für Benutzerschnittstellen, welche nur ein Objekt zu einer Zeit anzeigen.
Siehe auch: - selectNext:

selectNext:

- selectNext:sender
Dieses Aktionsverfahren ruft selectNext auf, gibt self zurück, falls selectNext YES zurückgibt, Null, falls es NO zurückgibt.

selectPrevious

- (BOOL)selectPrevious
Wählt das Objekt vor dem aktuell ausgewählten Objekt aus. Falls keine Objekte ausgewählt sind, dann wird das erste Objekt ausgewählt. Falls das erste Objekt ausgewählt ist, dann wird das letzte Objekt ausgewählt. Falls Mehrfachobjekte ausgewählt sind, wählt dieses Verfahren das Objekt vor dem ersten Objekt in der Auswahl aus. Dieses Verfahren führt dazu, daß eine setselectionIndexes:-Nachricht gesendet wird, und gibt den Wert zurück, welcher durch jene Nachricht zurückgegeben wird.
Dieses Verfahren ist nützlich für Benutzerschnittstellen, welche nur ein Objekt zu einer Zeit anzeigen.
Siehe auch: - selectPrevious:

selectPrevious:

- selectPrevious:sender
Dieses Aktionsverfahren ruft selectPrevious auf, gibt self zurück, falls selectPrevious YES zurückgibt, Null, falls es NO zurückgibt.

selectedObjects

- (NSArray *)selectedobjects
Gibt die ausgewählten Objekte zurück.
Siehe auch: - selectionIndexes

selectionIndexes

- (NSArray *)selectionIndexes
Gibt eine Matrix von NSNumber-Objekten zurück, welche die Indexe von ausgewählten Objekten in der Objektematrix der Steuerung identifizieren.
Siehe auch: - selectedObjects, - allObjects

selectFirstObjectAfterFetch

- (BOOL)selectsFirstObjectAfterFetch
Gibt YES zurück, falls die Steuerung das erste Ihrer Objekte nach Durchführen eines Abrufs auswählt, NO, falls nicht.
Siehe auch: - setSelectionIndexes:

setDataSource:

(void)setDataSource:(id < EODataSources> )aDataSource
Setzt die Datenquelle der Steuerung zu aDataSource, löscht die Auswahl und den Undo-Stapel und verwirft alle schwebenden Änderungen. Dieses Verfahren ruft das Anordnungsverfahren controller:didChangeDataSource: auf.
Siehe auch: - releaseUndos, - discardEdits, - clearSelection

setDelegate:

- (void)setDelegate:anObject
Setzt die Steuerungsanordnung auf anObject. Behält anObject nicht.

setMarksEveryOperation:

- (void)setMarksEveryOperation:(BOOL)flag
Setzt gemäß flag, ob die Steuerung einen Undo-Punkt für jede Einfügung, Löschung oder Editierung eines Objekts markiert. Steuerungen, welche durch Programmierung erzeugt sind, markieren nicht jede Operation durch Default-Einstellung, während jene, welche im Interface Builder erzeugt sind, dies tun.
Siehe auch: - markUndo, - deleteSelection

setMaximumUndoMarks:

- (void)setMaximumUndoMarks:(unsigned int)anInt
Setzt zu anInt die maximale Anzahl von Undo-Markierungen, welche registriert werden. Markierungen, welche nach der Maximalmenge hinzugefügt werden, führen dazu, daß frühere Markierungen verworfen werden. Dieses Verfahren ist nützlich, um die Speichernutzung zu beschränken. Setzen des Maximums auf 0 ermöglicht uneingeschränktes in-die-Schlange-einordnen von undos (undo queueing): dies ist die Default-Einstellung. Benutzen Sie setUndoEnabled:, um undo zu sperren.
Siehe auch: - undo

setNextController:

- setNextController:(EOController *)aController
Setzt die nächste Steuerung in der Steuerungskette zu aController. Siehe die Klassenbeschreibung für Information über die Steuerungskette.

SetSavesToDataSourceAutomatically:

- (BOOL)setSavesToDataSourceAutomatically:(BOOL)flag
Setzt gemäß flag, ob Operationen wie etwa Einfügen, Löschen und Aktualisieren mit Editierungen automatisch dazu führen, daß die Steuerung saveToDataSource durchführt. Gibt YES zurück, falls erfolgreich, NO, falls die Steuerung irgendwelche schwebenden Operationen für ihre Datenquelle aufweist.
Steuerungen, welche durch Programmierung erzeugt sind, sichern nicht automatisch durch Default-Einstellung, aber jene, welche im Interface Builder erzeugt sind, tun dies.
Siehe auch: - setSavesToObjectsAutomatically:

setSavesToObjectsAutomatically:

- (BOOL)setSavesToObjectsAutomatically:(BOOL)flag
Setzt gemäß flag, ob die Steuerung sofort saveToObject durchführt, wenn ein Objekt editiert wird. Gibt YES zurück, falls erfolgreich, NO, falls die Steuerung irgendwelche schwebende Editierungen für Ihre Objekt aufweist.
Steuerungen, welche durch Programmierung erzeugt sind, sichern nicht automatisch durch Default-Einstellung, aber jene, welche Interface Builder erzeugt sind, tun dies.
Siehe auch: - setSavesToDataSourceAutomatically:, - associationDidEdit,
- setValues:forObject:

setSelectionIndexes:

- (BOOL)setSelectionIndexes:(NSArray *)aSelection
Setzt die Auswahl als eine Matrix von NSNumber-Objekten. Gibt YES zurück, falls die Auswahl zu aSelecfion geändert wird, NO, falls nicht.
Die Steuerung sendet rekursiv isDiscardAllowed an alle Ihre Detail-Steuerungen, und falls irgendeine von ihnen NO zurückgibt, wird die Auswahl nicht geändert. Falls die Detail-Steuerungen Verwerten ermöglichen, ruft dieses Verfahren endEditing auf, setzt die Auswahlindexe und benachrichtigt seine Assoziierungen mit selectionDidChange. Schließlich sendet dieses Verfahren controllerDidChangeSelection: an die Anordnung.
Falls eine Assoziierung versucht, die Auswahl Ihrer Steuerung zu ändern und fehlschlägt, sollte die Assoziierung die Auswahl von ihrem Benutzerschnittstellenobjekt von der Auswahl der Steuerung rücksetzen. Sie kann dies tun, indem sie sich selbst einfach ein selectionDidChange-Verfahren sendet.

setSelectsFirstObjectAfterFetch:

- (void)setSelectsFirstObjectAfterFetch:(BOOL)flag
Setzt gemäß flag, ob die Steuerung das erste ihrer Objekte nach Durchführen eines Abrufs auswählt.
Siehe auch: - setSelectionIndexes:

setUndoEnabled:

- (void)setUndoEnabled:(BOOL)flag
Ermöglicht oder sperrt undo gemäß flag. Undo ist durch Default-Einstellung für Steuerungen, welche durch Programmierung erzeugt sind, nicht ermöglicht, obwohl es dies für Steuerungen, welche im Interface Builder erzeugt sind, ist.
Dieses Verfahren beeinflußt existierende Undo-Markierungen nicht. Sie können vorübergehend undo sperren, es dann wieder ermöglichen und einen undo durchführen; jedoch werden alle Änderungen, welche vorgenommen werden, während undo gesperrt war, nicht rückgesetzt.

setValues:forObject:

- (void)setValues:(NSDictionary *)newValues forObject:anEO
Wendet newValues auf anEO an, als ob Sie Editierungen wären, welche durch eine Assoziierung vorgenommen wurden. Falls die Steuerung nicht automatisch zu Objekten sichert, werden die neuen Werte als Editierungen gepuffert, welche tatsächlich zu anEO auf die nächste saveToObjects-Nachricht hin gesendet werden.
Falls die Steuerung automatisch zu Objekten sichert, dann werden die Änderungen sofort zu den Objekten gesichert.
Die Assozierungen der Steuerung werden nicht benachrichtigt, wenn eine Editierung mit diesem Verfahren vorgenommen wird. Sie sollten der Steuerung eine redisplay- Nachricht senden, nachdem Sie das Editieren von Objekten durch Programmierung beendet haben, um die Benutzerschnittstelle zu aktualisieren.
Siehe auch: - associationDidEdit, - savesToObjectsAutomatically

undo

- (void)undo
Setzt alle Änderungen in dem Undo-Stapel zu der letzten gesetzten Undo-Markierung zurück; eingefügte Objekte werden entfernt, gelöschte Objekte wiederhergestellt und alle Editierungen werden umgekehrt. Falls keine Undo-Markierungen gesetzt sind, tut es nichts.
Dieses Verfahren ruft zuerst saveToObjects auf, um alle Änderungen in dem Operationspuffer zu akkumulieren, von welchem sie rückgesetzt werden. Falls der Benutzer einen Wert editiert und die Steuerung jede Operation markiert, führt dies dazu, daß die Undo-Operation natürlich nur die gerade durchgeführte Editierung zurücksetzt.
Die Steuerung benachrichtigt ihre Anordnung, bevor sie Änderungen mit einer controllerWillUndo:-Nachricht zurücksetzt; falls die Anordnung NO zurückgibt, wird die Undo-Operation abgebrochen. Gleichermaßen sendet die Steuerung für jede zurückgesetzte Änderung ihrer Anordnung eine controller:willUndoObject:-Nachricht; falls die Anordnung NO zurückgibt, dann wird der undo für jenes Objekt übersprungen, aber die Undo-Operation geht weiter. Nachdem die Änderung zurückgesetzt ist, sendet die Steuerung controller:didUndoObject: an ihre Anordnung. Schließlich, nachdem alle Änderungen zurückgesetzt worden sind, sendet die Steuerung controllerDidUndo: an ihre Anordnung und contentsDidChange an ihre Assoziierungen. Falls die Auswahl der Steuerung sich ändert, sendet sie auch selectionDidChange an ihre Assoziierungen.
Siehe auch: - endEditing, - redisplay, - markUndo, - setMarksEveryOperation:,
- setUndoEnabled:

undo:

- undo:sender
Dieses Aktionsverfahren ruft undo auf und gibt self zurück.

Verfahren, welche durch die Anordnung implementiert sind

controller:association:didEditObject:key:value:

- (void)controller:(EOController *)controller
association(EOAssociation *)anAssociation
didEditObject:anEO
key:(NSString *)aKey
value:aValue
Gesendet von associationDidEdit, um die Anordnung zu informieren, daß anAssocition eine Editierung durchgeführt hat.

controller:didChangeDataSource:

- (void)controller:(EOController *)controller didChangeDataSource:(id < EODataSources> )aDataSource
Gesendet von setDataSource:, um die Anordnung zu informieren, daß die Datenquelle von controller jetzt aDataSource ist.

controllerDidChangeSelection:

- (void)controllerDidChangeSelection:(EOController *)controller
Sendet, wann immer sich die Auswahl von controller ändert, um die Anordnung über die Änderung zu informieren.

controller:didDeleteObject:

- (void)controller:(EOController *)controller didDeleteObject:anEO
Gesendet von irgendeiner der Löschungsverfahren, um die Anordnung zu informieren, daß controller anEO gelöscht hat.

controller:didDeleteObject:inDataSource:

- (void)controller:(EOController *)controller

didDeleteObject:anEO

inDataSource:aDataSource
Gesendet von saveToDataSource, um die Anordnung zu informieren, daß controller anEO von aDataSource gelöscht hat.

controller:didFetchObjects:

- (void)controller:(EOController *)controller didFetchObjects:(NSArray *)objects Gesendet von fetch, um die Anordnung zu informieren, daß controller das Unternehmensobjekt in objects von seiner Datenquelle abgerufen hat.

controller:didInsertObject:

- (void)controller:(EOController *)controller didInsertObject:anEO
Gesendet von saveToObjects, um die Anordnung zu informieren, daß controller anEO eingefügt hat.

controller:didInsertObject:inDataSource:

- (void)controller:(EOController *)controller
didInsertObject:anEO
InDataSource:aDataSource
Gesendet von saveToDataSource, um die Anordnung zu informieren, daß controller anEO in aDataSource eingefügt hat.

controller:didRollbackDataSource:

- (void)controller:(EOController *)controller didRollbackDataSource:(id < EODataSources> )aDataSource
Gesendet von saveToDataSource, um die Anordnung zu informieren, daß controller Änderungen in aDataSource rückgesetzt hat.

controllerDidSaveToDataSource:

- (void)controllerDidSaveToDataSource:(EOController *)controller
Gesendet von saveToDataSource, um die Anordnung zu informieren, daß controller das Sichern aller Operationen zu seiner Datenquelle beendet hat. Dieses Verfahren wird nur aufgerufen, falls alle Operationen erfolgreich gesichert wurden.

controller:didSaveToObject:

- (void)controller:(EOController *)controller didSaveToObject:anEO
Gesendet von saveToObjects, um die Anordnung zu informieren, daß controller Editierungen zu anEO gesichert hat.

controllerDidUndo:

- (void)controllerDidUndo:(EOController *)controller
Gesendet von undo, um die Anordnung zu informiereil, daß controller eine Undo- Operation durchgeführt hat.

controller:didUndoObject:

- (void)controller:(EOController *)controller didUndoObject:anEO
Gesendet von undo, um die Anordnung zu informieren, daß controller Änderungen an anEO rückgängig gemacht hat.

controller:didUpdateObject:inDataSource:

- (void)controller:(EOController *)controller
didUpdateabject:anEO
inDataSource:aDataSource
Gesendet von saveToDataSource, um die Anordnung zu informieren, daß controller anEO in aDataSource aktualisiert hat.

controller:failedToDeleteObject:inDataSource:

- (EODataSourceFailureResponse)controller:(EOController *)controller
failedToDeleteObject:anEO
InDataSource:aDataSource
Gesendet von saveToDataSource, um die Anordnung zu informieren, daß es controller nicht gelungen ist, anEO von aDataSource zu löschen. Falls die Anordnung EOContinueDataSourceFailureResponse zurückgibt, fährt controller damit fort, andere Änderungen zu der Datenquelle zu sichern.
Falls die Anordnung EORollbackDataSourceFailureResponse zurückgibt, sendet controller rollback (Rücksetzen) an seine Datenquelle, falls die Datenquelle auf jene Nachricht antwortet. saveToDataSource bricht dann ab und gibt ein Fehlschlagergebnis (failure result) zurück.
Beim Rücksetzen der Datenquelle ruft die Steuerung die Anordnungsverfahren controller:willRollbackDataSource: und controller:didRollbackDataSource: auf.

controller:failedTotnsertobject:inDataSource:

- (EODataSourceFailureResponse)controller:(EOController *)controller
failedToInsertObject:anEO
inDataSource:aDataSource
Gesendet von saveToDataSource, um die Anordnung zu informieren, daß es controller nicht gelungen ist, anEO in aDataSource einzufügen. Falls die Anordnung EOContinueDataSourceFailureResponse zurückgibt, fährt controller damit fort, andere Änderungen zu der Datenquelle zu sichern. Falls die Anordnung EORollbackDataSourceFailureResponse zurückgibt, sendet controller rollback an seine Datenquelle, falls die Datenquelle auf jene Nachricht antwortet. saveToDataSource bricht dann ab und gibt ein Fehlschlagergebnis zurück.
Beim Rücksetzen der Datenquelle, ruft die Steuerung die Anordnungsverfahren controller:willRollbackDataSource: und controller:didRollbackDataSource: auf.

controller:failedToUpdateObject:inDataSource:

- (EODataSourceFailureResponse)controller:(EOController *)controller
failedToUpdateObject:anEO
inDataSource:aDataSource
Gesendet von saveToDataSource, um die Anordnung zu informieren, daß es contro 1/er nicht gelungen ist, anEO in aDataSource zu aktualisieren. Falls die Anordnung EOContinueDataSourceFailureResponse zurückgibt, fährt controller damit fort, andere Änderungen zu der Datenquelle zu sichern. Falls die Anordnung EORollbackDataSourceFailureResponse zurückgibt, sendet controller rollback an seine Datenquelle, falls die Datenquelle auf jene Nachricht antwortet. saveToDataSource bricht dann ab und gibt ein Fehlschlagergebnis zurück.
Beim Rücksetzen der Datenquelle, ruft die Steuerung die Anordnungsverfahren controller:willRollbackDataSource: und controller:didRollbackbataSource: auf.

controller:object:failedToPrepareForDataSource:

- (EODataSourceFailureResponse)controller:(EOController *)controller
object:anEO
failedToPrepareForDataSource:aDataSource
Gesendet von saveToDataSource, wenn anEO NO von einer prepareForDataSource- Nachricht zurückgibt. Falls die Anordnung EOContinueDataSourceFailureResponse zurückgibt, fährt controller damit fort, andere Änderungen zu der Datenquelle zu sichern. Falls die Anordnung EORollbackDataSourceFailureResponse zurückgibt, sendet controller rollback an seine Datenquelle, falls die Datenquelle auf jene Nachricht antwortet. saveToDataSource bricht dann gibt und ein Fehlschlagergebnis zurück.

controller:saveObjectsFailedForDataSource:

- (void)controller:(EOController *)controller
saveObjectsFailedForDataSource:aDataSource
Gesendet von saveToDataSource, um die Anordnung zu informieren, daß aDataSource NO von einer saveObjects-Nachricht zurückgegeben hat.

controller:willDeleteObject:

- (BOOL)controller:(EOController *)controller wiilDeleteObject:anEO
Gesendet von irgendeinem der Löschungsverfahren, um die Anordnung zu informieren, daß controller anEO löschen wird. Falls die Anordnung NO zurückgibt, wird die Löschung nicht durchgeführt und saveToObjects wird abgebrochen; falls die Anordnung YES zurückgibt, geht die Löschung weiter.

Controller:willDeleteObject:inDataSource:

- (BOOL)controller:(EOController *)controller
willDeleteObject:anEO
inDataSource:aDataSource
Gesendet von saveToDataSource, um die Anordnung zu informieren, daß controller anEO von aDataSource löschen wird. Falls die Anordnung NO zurückgibt, wird die Löschung nicht durchgeführt (obwohl saveToDataSource für andere Operationen fortfährt); falls die Anordnung YES zurückgibt, geht die Löschung weiter

controllerWillDiscardEdits:

- (BOOL)controllerWillDiscardEdits:(EOController *)controller
Gesendet von IsDiscardAllowed, um die Anordnung zu informieren, daß controller dabei ist, schwebende Editierungen zu verwerfen. Falls die Anordnung dieses Verfahren nicht implementiert, öffnet controller ein Abruffeld, welches den Benutzer warnt, daß Editierungen verworfen werden können. Falls die Anordnung NO zurückgibt, dann gibt IsDiscardAllowed NO zurück; falls die Anordnung YES zurückgibt, dann geht IsDiscardAllowed weiter.
Falls die Anordnung sicherstellen möchte, daß Editierungen erhalten werden, kann es explizit saveToObjects an controller senden.

controllerWillDiscardOperations:

- (BOOL)controllerWillDiscardOperations:(EOController *)controller
Gesendet von IsDiscardAllowed, um die Anordnung zu informieren, daß controller dabei ist, schwebende Operationen zu verwerfen, welche für ihre Datenquelle bestimmt sind. Falls die Anordnung dieses Verfahren nicht implementiert, öffnet controller ein Abruffeld, welches den Benutzer warnt, daß Aktualisierungen verworfen werden können. Falls die Anordnung NO zurückgibt, dann gibt IsDiscardAllowed NO zurück; falls die Anordnung YES zurückgibt, dann geht IsDiscardAllowed weiter.
Falls die Anordnung sicherstellen möchte, daß Aktualisierungen erhalten werden, kann es explizit saveToDataSource an controller senden.

controllerWillFetch:

- (BOOL)controllerWillFetch:(EOController *)controller
Aufgerufen von fetch, um die Anordnung zu informieren, daß controller dabei ist, abzurufen. Falls die Anordnung NO zurückgibt, wird der Abruf abgebrochen; falls die Anordnung YES zurückgibt, geht der Abruf weiter.

controller:willInsertObject:atindex:

- (BOOL)controller:(EOController *)controller
willInsertObject:anEO
AtIndex:(unsigned int)anIndex
Gesendet von InsertObject:AtIndex:, um die Anordnung zu informieren, daß controller anEO in seine Objektmatrix bei anIndex einfügen wird. Falls die Anordnung NO zurückgibt, wird die Einfügung abgebrochen; falls die Anordnung YES zurückgibt, geht die Einfügung weiter. Die Anordnung kann anEO modifizieren, normalerweise indem es seinen Primärschlüssel auf einen einzigen Wert setzt.

controller:willInsertObject:inDataSource:

(BOOL)controller:(EOController *)controller
will InsertObjectanEO
inDataSource:aDataSource
Gesendet von saveToDataSource, um die Anordnung zu informieren, daß oontroller anEO in aDataSource einfügen wird. Falls die Anordnung NO zurückgibt, wird die Einfügung nicht durchgeführt (obwohl saveToDataSource für andere Operationen fortfährt); falls die Anordnung YES zurückgibt, geht die Einfügung weiter.

controller:willRollbackDataSource:

- (void)controller:(EOController *)controller willRollbackDataSource:(id < EODataSources> )aDataSource
Gesendet von saveToDataSource, um die Anordnung zu informieren, daß controller Änderungen in aDataSource rücksetzen wird. Die Anordnung kann diese Operation nicht verhindern, aber kann jede Aktion, welche sie auch immer benötigt, ergreifen, basierend auf dieser Information.

controller:willSaveEdits:toObject:

- (NSDictionary *)controller:(EOController *)controller
willsaveEdits:(NSDictionary *)newValues
toObject:anEO
Gesendet von saveToObjects, um die Anordnung zu informieren, daß controller edits zu anEO sichern wird. newValues ist ein Verzeichnis von Schlüsselwertpaaren, deren Schlüssel die Namen von Eigenschaften sind, welche zu anEO gehören und deren Werte die neuen Werte sind, welche anEO für jene Eigenschaften gegeben werden. Die Anordnung kann die Werte wie sie sind zurückgeben, oder kann einen Ersatz- Wertesatz zum Anwenden auf das Objekt zurückgeben. Falls die Anordnung Null zurückgibt, wird die Sicherung nicht durchgeführt und saveToObjects wird abgebrochen.

controllerWillSaveToDataSource:

- (BOOL)controllerWillSaveToDataSource:(EOController *)controller
Gesendet von saveToDataSource, um die Anordnung zu informieren, daß controller Änderungen zu ihrer Datenquelle sichern wird. Falls die Anordnung NO zurückgibt, wird die Sicherung abgebrochen; falls die Anordnung YES zurückgibt, geht die Sicherung weiter.

controllerWillUndo:

- (BOOL)controllerWillUndo:(EOController *)controller
Gesendet von undo, um die Anordnung zu informieren, daß controller Änderungen rückgängig machen wird. Falls die Anordnung NO zurückgibt, wird die Undo-Operation abgebrochen; falls die Anordnung YES zurückgibt, geht die Undo-Operation weiter.

controller:willUndoObject:

- (BOOL)controller:(EOController *)controllerwillUndoObject:anEO
Gesendet von undo, um die Anordnung zu informieren, daß controller Änderungen, welcher vorher an anEO vorgenommen wurden, rückgängig machen wird. Falls die Anordnung NO zurückgibt, wird die Undo-Operation nur für anEO abgebrochen (die größere Undo-Operation geht weiter); falls die Anordnung YES zurückgibt, geht die Undo-Operation für anEO weiter.

controller:willUpdateObject:inDataSource:

- (BOOL)controller:(EOController *)controller
willUpdateObject:anEO
inDataSource:aDataSource
Gesendet von saveToDataSource, um die Anordnung zu informieren, daß controller anEO in aDataSource aktualisieren wird. Falls die Anordnung NO zurückgibt, wird die Aktualisierung nicht durchgeführt (obwohl saveToDataSource mit anderen Operationen fortfährt); falls die Anordnung YES zurückgibt, geht die Aktualisierung weiter.

Klassenbeschreibung

EOAssociation ist eine abstrakte Klasse, welche die Verbindung zwischen einem EOController, welcher eine Sammlung von datentragenden Unternehmensobjekten verwaltet, und einem einzelnen Benutzerschnittstellenelement, wie etwa einer Spalte in einem NXTabieView, oder einer Steuerung definiert. Eine EOAssociation koordiniert die Anzeige und das Editieren von Eigenschaftenwerten für ihre Steuerungsunternehmensobjekte. EOAssociations kann auch zwei Steuerungen verbinden (siehe die EOQualifiedAssociation-Klassenbeschreibung für Information).
Eine EOAssociation verbindet nur eine Eigenschaft der Objekte, welche durch ihren EOController zu ihrem Benutzerschnittstellenobjekt geliefert werden. Diese Eigenschaft wird durch einen Schlüssel, wie in dem informellen EOKeyValueCoding-Protokoll der Zugriffsebene benutzt, identifiziert. Eine Assoziierung für ein Benutzerschnittstellenobjekt, welches in der Lage ist, Mehrfach-Unternehmensobjekte (wie etwa ein NXTableView) anzuzeigen, zeigt Daten für alle Objekte in der Steuerung an, während eine Assoziierung für ein Benutzerschnittstellenobjekt, welches nur in der Lage ist, ein Unternehmensobjekt (wie etwa ein TextField) anzuzeigen, zeigt Daten für das erste ausgewählte Objekt in der Steuerung an.
Eine EOAssociation wird von Änderungen in seiner Steuerung durch das EOAssociationNotification-Protokoll benachrichtigt. Auf das Empfangen einer Benachrichtigung einer Änderung hin, bestimmt die Assoziierung, welche Objekte es benötigt, um Werte dafür anzuzeigen, und sendet jedem eine valuesForKeys:-Nachricht mit einer Matrix, welche den Schlüssel für die Eigenschaft der Assoziierung enthält. Die Assoziierung aktualisiert dann das Benufzerschnittstellenobjekt mit dem zurückgegebenen Wert, falls er zu dem aktuellen Wert verschieden ist.
Falls sich das Benutzerschnittstellenobjekt der EOAssociation ändert, dann muß die EOAssociation jene Änderung an ihre Steuerung senden. EOAssociations stellen sich normalerweise als die Targets eines Steuerungsobjekts auf, so daß sie von solchen Änderungen benachrichtigt werden. Zum Beispiel, wenn ein Benutzer ein TextField, welches den Namen eines Unternehmensobjekts darstellt, editiert und return drückt, sendet das TextField seiner Assoziierung eine Aktionsnachricht. Die EOAssociation erhält dann den neuen Wert in dem TextField und informiert ihre Steuerung, daß sich das Benutzerschnittstellenobjekt geändert hat, indem es der Steuerung eine associationDidEdit:-Nachricht sendet. Als Antwort auf diese Benachrichtigung sendet die Steuerung eine Value-Nachricht an die Assoziierung, um den neuen Wert für das Unternehmensobjekt zu erhalten.
Für mehr Information darüber, wie EOAssociations mit EOControllers und Benutzerschnittstellenobjekten arbeiten, siehe die EOController-Klassenbeschreibung und die EOAssociationNotification-Protokollbeschreibung. Für Information über Assoziierungen für eine spezielle Zielklasse, siehe eine der folgenden Klassenbeschreibungen:

Assozüerungsunterklasse Zielobjektklasse

EOActionCellAssociation Jegliche ActionCell-Unterklasse (wie etwa TextFieldCell)
EOBrowserAssociation NXBrowser
EOButtonAssociation Button
EOColumnAssociation NXTableVector (in einem NXTableView)
EOControlAssociation Siehe unten
EOImageAssociation NXImageView
EOMatrixAssociation Matrix (aber siehe unten)
EOPopUpAssociation PopUpList
EOQualifiedAssociation EOController
EOTextAssociation Text
EOControlAssociation kann mit jeder "einfachen" Steuerung benutzt werden, welche einen einzelnen Wert verwaltet, wie etwa ein TextField oder ein Slider (Schieber). Jedoch sollten Sie, falls eine Steuerung eine zugeordnete Assozüerungsunterklasse aufweist, jene benutzen. Zum Beispiel sollte Buttons mit Instanzen von EOButtonAssociation verbunden werden.
Beachten Sie: EOMatrixAssociation hat eine sehr eingeschränkte Funktionalität. Falls Sie Assoziierung mit individuellen Elementen in einer Matrix (insbesondere mit Feldern in einem Form-Objekt) erzeugen möchten, benutzen Sie EOActionCellAssociation.
Obwohl die Schnittstelle von jeder Assoziierungen nur ein paar Verfahren enthält, sind ihre Implementierungen oftmals in hohem Grade voneinander und von der Weise, wie Zielobjekte agieren, abhängig. Deswegen sollten Sie, falls Sie eine Assoziierungsklasse für eine benutzerspezifische Benutzerschnittstellenobjektklasse erzeugen müssen, sie als eine direkte Unterklasse von EOAssociation erzeugen.

Instanzvariablen

Keine in dieser Klasse deklariert.

Adoptierte Protokolle

EOAssociationNotification - contentsDidChange
- selectionDidChange
- discardEdits
- endEditing

Verfahrenstypen

Initialisieren von neuen Instanzen - initWithController:key:destination:
Erhalten von Assoziierungsmitgliedern - controller
- destination
Erhalten des Schlüssels - key
und des Wertes - value

Instanzverfahren

controller

- (EOController *)controller
Gibt den EOController zurück, welcher für die Assoziierung verantwortlich ist.

destination

- destination
Gibt das Objekt zurück, welches die Assoziierung überwacht. Dies ist typischerweise ein Benutzerschnittstellenobjekt, muß aber keines sein.

InitWithController:key:destination:

- InitWithController:(EOController *)acontroller
key:(NSString *)akey
destination:destination
Initialisiert eine neu zugewiesene EOAssociation mit aController. akey ist der Name der Eigenschaft, welche durch die Assoziierung dargestellt wird, und wird als der Identifizierer für Wertübermittlungen zu und von destination (typischerweise ein Benutzerschnittstellenobjekt oder ein anderer EOController) benutzt. Dies ist der festgelegte Initialisierer für die EOAssociation-Klasse. Gibt self zurück.
Siehe auch: - addAssociation: (EOController)

key

- (NSString *)key
Gibt den Namen der Eigenschaft zurück, welchen die Assoziierung zu und von ihrem Ziel übermittelt.

value

- value
Gibt den Wert des Ziels der Assoziierung als eine Instanz einer geeigneten Wertklasse (siehe "Mapping from Database to Objects" in der EOAttribute-Klassenbeschreibung der Zugriffsebene) zurück. Zum Beispiel ist die Wertklasse für einen Wert von TextField NSString.
Für Anwendungen, welche die Zugriffsebene benutzen, falls die Wertklasse, welche für ein Unternehmensobjektattribut in dem EOModel spezifiziert ist, nicht NSString oder NSData ist, muß es exakt mit der Wertklasse, welche durch die Assoziierung benutzt wird, übereinstimmen.
Siehe auch: - key, - takeValuesFromDictionary:(informelles EOKeyValueCoding- Protokoll)

Klassenbeschreibung

EOActionCellAssociation ist eine Assoziierung, welche mit einer individuellen Zelle einer Steuerung wie etwa einer Matrix arbeitet. Eine Zellenassoziierung wird benötigt, weil eine Steuerung nur eine Einzeltextanordnung für alle ihre Zellen anbietet, aber eine Assoziierung, welche mit einer Zelle verbunden ist, wissen muß, wann ihre eigene Zelle das Editieren beendet hat. Falls Sie mehrere EOActionCellAssociations mit einer Matrix aufstellen, zum Beispiel, kann nur eine die Textanordnung sein, was es für eine andere schwer macht, benachrichtigt zu werden, wenn ihre Zelle das Editieren beendet. Um dieses Problem abzuwenden, registrieren sich EOActionCellAssociations global gemäß ihrer Zielzellen. Wenn ihr Steuerungsobjekt das Editieren beendet, schaut die Assoziierung, welche als die Steuerungstextanordnung registriert ist, die Assoziierung für die ausgewählte Zelle der Steuerung nach und gibt die Benachrichtigung dazu bekannt.
Obwohl die Schnittstelle von jeder Assoziierung nur ein paar Verfahren enthält, sind verschiedene Implementierungen oftmals in hohem Grade voneinander und von der Weise, wie die Zielobjekte agieren, abhängig. Deswegen sollten Sie, falls Sie eine Assoziierungsklasse für benutzerspezifische Unterklasse von ActionCell erzeugen müssen, sie als eine direkte Unterklasse von EOAssociation erzeugen.

Instanzvariablen

Keine in dieser Klasse deklariert.

Instanzverfahren

Keines in dieser Klasse deklariert.

Klassenbeschreibung

Eine EOColumnAssociation zeigt eine Spalte eines NXTableView, welche die Werte für ihre Schlüssel von allen Unternehmensobjekten in ihrer Steuerung enthält, an und editiert diese. Sie können jegliche Anzahl von Spaltenassoziierungen an ein einzelnes NXTableView anhängen, solange sie alle die gleiche Steuerung aufweisen.
Jedoch muß, weil ein NXTableView erwartet, daß nur ein einzelnes Objekt als seine Datenquelle (nicht zu verwechseln mit der Datenquelle der Steuerung) agiert, eine der Spaltenassoziierungen vorwärts treten, um jene Rolle zu spielen. Die Spaltenassoziierungen für eine spezielle Steuerung und NXTableView wissen sich unter dieser Führungsassoziierung zu treffen, welche sich selbst und ihre Kohorten als Spaltenidentifizierer benutzt und Abfragen für Datenzugriff zu der geeigneten Assoziierung weiterleitet.
Obwohl die Schnittstelle von jeder Assoziierung nur ein paar Verfahren enthält, sind verschiedene Implementierungen oftmals in hohem Grade voneinander und von der Weise, wie die Zielobjekte agieren, abhängig. Deswegen, sollten Sie, falls Sie eine Assoziierungsklasse für eine benutzerspezifische Unterklasse von NXTableVector erzeugen müssen, sie als eine direkte Unterklasse von EOAssociation erzeugen.

Editierungspufferung

Da ein NXTableView Daten nicht selbst speichert, müssen EOColumnAssociations ihre editierten Werte (in anderen Worten, gepufferte Editierungen, welche noch nicht zur Steuerung gesendet wurden) zwischenspeichern. Wenn sie gefragt wird, einen Wert für einen bestimmten Index zu erhalten, fragt die Assoziierung ihre Steuerung für das Unternehmensobjekt an jenem Index und schaut nach einem Wert, welcher unter jenem Objekt zwischengespeichert ist. Nur, falls sie keinen findet, fragt sie das Unternehmensobjekt nach seinem Wert. Wenn die Steuerung zu Objekten sichert, werden allen ihren Spaltenassoziierungen (und jeglichen anderen Assoziierungen, welche Editierungen puffern) discardEdits-Nachrichten gesendet, welche Ihnen mitteilen, Ihre zwischengespeicherten Werte zu löschen.

Aufstellen einer EOColumnAssociation

Wenn Sie eine EOColumnAssociation durch Programmierung aufstellen, müssen Sie die neu initialisierte Assoziierung konfigurieren, indem Sie ihr eine setTableView:-Nachricht mit dem NXTableView der Zielspalte als ein Argument senden. Dieses Verfahren stellt die Assoziierung als die Datenquelle und die Anordnung des NXTableView auf, falls benötigt. Siehe die Verfahrensbeschreibung für mehr Information.

Instanzvariablen

Keine in dieser Klasse deklariert.

Klassenbeschreibung

EOControlAssociation ist die Default-Assoziierung für alle Unterklassen von Control außer Button, Fdrm, Matrix, NXBrowser und NXImageView. Es setzt seine Steuerungswerte mit setStringValue: und erhält seine Steuerungswerte durch Aufrufen von stringValue. Eine Steuerungsassoziierung arbeitet somit gut mit jeder "einfachen" Steuerung, welche nur einen einzigen Wert anzeigt, wie etwa einem TextField oder Slider.
Eine Steuerungsassoziierung stellt sich selbst als das Target seiner Zielsteuerung auf, und, falls jene Steuerung auf die setTextAnordnunge:-Nachricht antwortet, als die Textanordnung der Steuerung. Dies ermöglicht einer Steuerungsassoziierung, Ihrer Steuerung eine Editierung mitzuteilen, wann immer ihre Steuerung eine Aktionsnachricht sendet und wann immer ihre Steuerung das Editieren beendet (zum Beispiel dadurch, daß der Benutzer Tab oder Return drückt oder ein anderes Textfeld auswählt).
Obwohl die Schnittstelle von jeder Assoziierung nur ein paar Verfahren enthält, sind ihre Implementierungen oftmals in hohem Grade voneinander und von der Weise, wie die Zielobjekte agieren, abhängig. Deswegen sollten Sie, falls Sie eine Assoziierungsklasse für eine benutzerspezifische Unterklasse von Control erzeugen müssen, sie als eine direkte Unterklasse von EOAssociation erzeugen.

Instanzvariablen

Keine in dieser Klasse deklariert.

Instanzverfahren

Keines in dieser Klasse deklariert.

Klassenbeschreibung

Eine EOImageAssociation benutzt ein NXImageView, um ein NXImage für den geeigneten Schlüssel von dem ausgewählten Objekt ihrer Steuerung anzuzeigen, und setzt ein neues Bild für jenes Objekt, wenn eines über den NXImageView gezogen wird.
Obwohl die Schnittstelle von jeder Assoziierung nur ein paar Verfahren enthält, sind verschiedene Implementierungen oftmals in hohem Grade voneinander und von der Weise, wie die Zielobjekte agieren, abhängig. Deswegen sollten Sie, falls Sie eine Assoziierungsklasse für eine benutzerspezifische Unterklasse von NXImageView erzeugen müssen, sie als eine direkte Unterklasse von EOAssociation erzeugen.

Instanzvariablen

Keine in dieser Klasse deklariert.

Instanzverfahren

Keines in dieser Klasse deklariert.

Klassenbeschreibung

Eine EOMatrixAssociation verwaltet eine Matrix von ButtonCells als eine Auswahlliste, wobei sie Zellen für jedes Objekt in ihrer Steuerung hinzufügt und die Werte für ihren Schlüssel anzeigt. Um richtig mit einer Matrixassoziierung zu arbeiten, sollte eine Matrix ButtonCells des Typs NX ONOFF benutzen, einen Modus von NX RADIOMODE aufweisen und in einem ScrollView enthalten sein. Diese Konfiguration ermöglicht es Ihnen, die Matrix zu benutzen, um ein einzelnes Objekt zu einer Zeit auszuwählen.
EOBrowserAssociation bietet eine flexiblere Auswahlliste als EOMatrixAssociation, da ein NXBrowser leere und mehrfache Auswahlen, zusätzlich zu der üblichen ein Objekt zu einer Zeit, ermöglichen kann. Eine browser-basierte Auswahlliste ist auch leichter aufzustellen, da es über das Verbinden der Assoziierung hinaus keine Extrakonfiguration zu erstellen gibt.
Obwohl die Schnittstelle von jeder Assoziierung nur ein paar Verfahren enthält, sind verschiedene Implementierungen oftmals in hohem Grade voneinander und von der Weise, wie die Ziefobjekte agieren, abhängig. Deswegen sollten Sie, falls Sie eine Assoziierungsklasse für eine benutzerspezifische Unterklasse von Matrix erzeugen müssen, sie als eine direkte Unterklasse von EOAssociation erzeugen.

Instanzvariablen

Keine in dieser Klasse deklariert.

Instanzverfahren

Keines in dieser Klasse deklariert.

Klassenbeschreibung

Eine EOPopUpAssociation nützt eine Popup-Liste, um den Wert eines Unternehmensobjekts für ihren Schlüssel anzuzeigen, und benachrichtigt ihre Steuerung, wenn der Benutzer ein neues Element in der Popup-Liste auswählt. Um eine Popup- Assoziierung aufzustellen, müssen Sie die Popup-Liste im Interface Builder erzeugen und sie manuell mit Elementen bestücken, welche die möglichen Werte für den Assoziierungsschlüssel darstellen. Sie gestalten dann die Assoziierung von der Steuerung zu der Taste der Popup-Liste.
Wenn die Assoziierung von einer Änderung durch ihre Steuerung benachricht wird, erhält sie den Wert des zuerst ausgewählten Unternehmensobjekt und schaut nach einem übereinstimmenden Zeichenkettenwert in den Elementen der Popup-Liste. Falls Sie ein Element findet, welches gleich dem Wert des Unternehmensobjekts ist, läßt Sie die Popup-Liste jenes Element auswählen. Falls sie kein Element mit dem Wert findet, erzeugt sie vorübergehend ein Extraelement mit jenem Wert, fügt es dem unteren Ende der Popup-Liste hinzu und läßt die Popup-Liste es auswählen. Das nächste Mal, wenn die Assoziierung von einer Änderung in der Auswahl oder von Inhalten durch ihre Steuerung benachrichtigt wird, entfernt sie das temporäre Element von der Popup-Liste. Durch das temporäre Hinzufügen von Elementen zu ihrer Popup-Liste garantiert die Assoziierung, daß der richtige Gegenstand angezeigt wird, sogar für einen Wert außerhalb des Satzes von "legalen" Werten.
Wenn der Benutzer ein Element in der Popup-Liste auswählt, sendet die Assoziierung einfach eine associationDidEdit:-Nachricht an ihre Steuerung. Ein Wert der EOPopUp- Association ist der Zeichenkettenwert des ausgewählten Elements in der Popup-Liste, so daß dieses Element als der neue Wert für das Unternehmensobjekt benutzt wird.
Beachten Sie, daß falls ein temporäres Element der Popup-Liste hinzufügt wurde, es sofort entfernt wird, falls der Benutzer ein verschiedenes auswählt.
Obwohl die Schnittstelle von jeder Assoziierung nur ein paar Verfahren enthält, sind verschiedene Implementierungen oftmals in hohem Grade voneinander und von der Weise, wie die Zielobjekte agieren, abhängig. Deswegen sollten Sie, falls Sie eine Assoziierungsklasse für eine benutzerspezifische Unterklasse von PopUpList erzeugen müssen, sie als eine direkte Unterklasse von EOAssociation erzeugen.

Instanzvariablen

Keine in dieser Klasse deklariert.

Instanzverfahren

Keines in dieser Klasse deklariert.

Klassenbeschreibung

Die EOQualifiedAssociation-Klasse implementiert Assoziierungen zwischen EOControllers. Oftmals werden mehrere Elemente in der Benutzerschnittstelle durch eine Master-Detailrelation verbunden. EOQualifiedAssociations stellen diese Verbindungen her. Wenn ein EOController eine saveToObjects-, saveToDataSource- oder redisplay- Nachricht empfängt, gibt sie jene Aktion nicht nur an ihre nächste Steuerung bekannt, sondern überprüft auch jede Assoziierung, um zu sehen, ob ihr Ziel jene Aktion durchführen kann, in welchem Fall sie auch dem Assoziierungsziel die Aktion bekannt gibt. Das Ziel muß jedoch nicht durch eine EOQualifiedAssociation verbunden sein; es muß nur auf die geeigneten Nachrichten antworten und irgendeine Art von Assoziierung aufweisen, welche richtig damit funktioniert.
Wenn eine EOQualifiedAssociation ein contentsDidChange oder selectionDidChange von ihrer Steuerung (dem Master) empfängt, muß es seine Zielsteuerung (das Detail) requalifizieren. Sie tut dies, indem sie das ausgewählte Objekt von der Master-Steuerung erhält und sie qualifyWithRelationshipKey:ofObject: (beschrieben in der EOQualifiableDataSources-Protokollbeschreibung) benutzt, um die Datenquelle von ihrer Zielsteuerung mit dem Assoziierungsschlüssel und dem ausgewählten Objekt zu qualifizieren, und dann die Zielsteuerung abrufen läßt, um ihre Anzeige zu aktualisieren. Eine Detail-Steuerung kann nur bedeutungsvoll Werte anzeigen, wenn genau ein Objekt in dem Master ausgewählt ist; falls die Master-Steuerung nicht genau ein Objekt ausgewählt hat, feitet die Assoziierung Null als das Objekt weiter, für welches zu qualifizieren ist, was die Detail-Steuerung sperrt.
Für eine EOQualifiedAssociation ist es möglich, mit einer Detail-Steuerung aufgestellt zu werden, welche noch keine Datenquelle hat. In diesem Fall wird die Assoziierung eine Detail-Datenquelle von dem Master erhalten, indem sie ihm eine dataSourceQualifiedByKey:-Nachricht (beschrieben in der EOMasterDataSources- Protokollbeschreibung) sendet. Sie weist dann die neue Datenquelle der Detail-Steuerung zu, indem sie ihr eine setDataSource:-Nachricht sendet.

Instanzvariablen

Keine in dieser Klasse deklariert.

Instanzverfahren

Keines in dieser Klasse deklariert.

Instanzverfahren

setTableView:

- (void)setTableView:(NXTableView *)aTable View
Falls aTableView noch keine Spaltenassoziierung von der gleichen Steuerung wie seine Datenquelle aufweist, stellt es den Empfänger als die Datenquelle und die Anordnung auf, so daß er anstelle von allen anderen Spaltenassoziierungen, welche an aTableView gebunden sind, agiert. Sie sollten diese Nachricht immer zu einer Spaltenassoziierung senden, welche Sie durch Programmierung erzeugen.

tableView

- (NXTableView *)tableView
Gibt den NXTableView zurück, welcher die Zielspalte der Assoziierung enthält.

Klassenbeschreibung

Eine EOTextAssociation verwaltet ein Text-Objekt und ist in der Lage, ein Anzeigen von ASCII, RTF und serialisierten RTF mit Attachments (RTFD) zu handhaben. Eine Textassoziierung überwacht jegliches Editieren, welches an dem Text-Objekt vorgenommen wird, und wenn das Text-Objekt das Editieren beendet (zum Beispiel, falls der Benutzer Enter drückt), informiert die Textassoziierung ihre Steuerung.
Wenn eine Textassoziierung durch ihre Steuerung von einer Änderung benachrichtigt wird, erhält sie den Wert des zuerst ausgewählten Unternehmensobjekts als Rohzeichendaten und überprüft ihn auf eine RTF- oder RTFD-Signatur. Die Assoziierung sendet dann die passende Nachricht an ihr Text-Objekt für das Format, was dem Text-Objekt ermöglicht, den Wert unbeachtlich des Formats richtig anzuzeigen.
Wenn nach ihrem Wert gefragt, gibt Textassoziierung jedoch ein NSString (NSData für RTFD) zurück, welches den Text in dem Format enthält, welches auch immer Ihr Text- Objekt benutzt:

Text-Fähigkeit Text-Format

Einzel-Schriftzeichensatz Einfacher Text in einem NSString-Objekt
Mehrfach-Schriftzeichensätze ermöglicht RTF in einem NSString-Objekt
Graphiken ermöglicht RTFD in einem NSData-Objekt
Dies kann Probleme verursachen, falls Sie einen Schlüssel, dessen entsprechender Wert von einem Typ (wie etwa einfacher Text) ist, mit einem Text-Objekt assoziieren, welches dazu konfiguriert ist, einen anderen Typ (wie etwa RTF) zu editieren. In diesem Fall empfangen die Unternehmensobjekte Text in einem Format, welches Sie möglicherweise nicht handhaben können. Sie sollten immer Sorge tragen, die Textformate der Werte, welche Sie anzuzeigen beabsichtigen, an die Konfiguration des Text-Objekts anzupassen.
Obwohl die Schnittstelle von jeder Assoziierung nur ein paar Verfahren enthält, sind verschiedene Implementierungen oftmals in hohem Grade voneinander und von der Weise, wie die Zielobjekte agieren, abhängig. Deswegen sollten Sie, falls Sie eine Assoziierungsklasse für eine benutzerspezifische Unterklasse von Text erzeugen müssen, sie als eine direkte Unterklasse von EOAssociation erzeugen.

Instanzvariablen

Keine in dieser Klasse deklariert.

Instanzverfahren

Keines in dieser Klasse deklariert.

Protokollbeschreibung

Das EOAssociationNotification-Protokoll deklariert Verfahren, welche durch einen EOController gesendet wurden, um seinen EOAssociations Änderungen an seinen Unternehmensobjekten mitzuteilen. Wann immer ein Objekt durch eine Steuerung geändert wird, ob durch eingefügt, gelöscht oder aktualisiert werden, sendet die Steuerung jeder ihrer EOAssociations eine contentsDidChange-Nachricht, welche der Assoziierung ermöglicht, jegliche neuen Werte anzuzeigen. Falls die Änderung an der Steuerung auch eine Änderung der Auswahl einschließt, sendet es selectionDidChange an jede Assoziierung, so daß die Assoziierung Werte für das richtige Objekt anzeigen kann oder die ausgewählten Objekte hervorheben kann, falls ihr Benutzerschnittstellenobjekt Mehrfachwerte anzeigt.
Die Steuerung informiert auch ihre Assoziierungen, wenn eine Operation, welche sie durchführt, jegliche zwischengespeicherten Werte für die Benutzerschnittstellenobjekte löschen würde. Wenn die Steuerung ihre gepufferten Editierungen sichert oder verwirft, macht sie jegliche editierten Werte, welche durch ihre Assoziierungen zwischengespeichert sind, irrelevant - und so sendet sie jeder Assoziierung eine discard- Edits-Nachricht. Zum Beispiel speichert ein NXTableView tatsächlich nicht die Werte, welche es anzeigt, aber erhält sie durch ein anderes Objekt, wie etwa eine EOColumnAssociation. Das Assoziierungsobjekt speichert tatsächlich jegliche editierten Werte für die Spalte und discardEdits informiert die Assoziierung, daß die zwischengespeicherten Werte, welche sie aufweist, nicht länger anwendbar sind.
Jede andere Operation, welche die Steuerung durchführt - Abrufen, Einfügen eines neues Objekts, Setzen einer Undo-Markierung - erfordert, daß das Editieren eines Benutzerschnittstellenobjekts beendet wird. In diesem Fall sendet die Steuerung endEditing an jede ihrer Assoziierungen, so daß sie das Editieren beenden, jegliche gemeinsam genutzten Resourcen (wie etwa window's field editor) zurückfordern und die Steuerung mit associationDidEdit: benachrichtigen können.

Implementieren des EOAssociationNotification-Protokolls

Die Beschreibungen in dieser Beschreibung stellen alle Details darüber bereit, was die Verfahren tun sollten, aber es gibt ein paar Punkte beim Implementieren von ihnen, deren Sie sich bewußt sein müssen. Da eine Assoziierung nicht nur Nachrichten von ihrer Steuerung empfängt, sondern sie auch zu Ihrer Steuerung sendet, könnte eine rekursive Schleife entstehen, falls Ihre Assozüerungsunterklasse Nachrichten zurück an ihre Steuerung von einem der Benachrichtigungsverfahrens dieses Protokolls sendet. Zum Beispiel, falls Ihre Assoziierung die Auswahl der Steuerung in ihrer eigenen selectionDidChange-Nachricht verändern muß, wird ihr eine andere selectionDidChange- Nachricht gesendet, während sie immer noch die erste handhabt. Sie sollten entweder Ihre Assoziierung dazu implementieren, die Auswahl oder Werte der Steuerung nicht zu beeinflussen, oder Sie sollten sich einen Mechanismus ausdenken, um das Assoziierungsbenachrichtigungsverfahren davor zu schützen, rekursiv aufgerufen zu werden.
Eine andere Nebenüberlegung stammt von der engen Beziehung zwischen einer Assoziierung und ihrem Benutzerschnittstellenobjekt. Eine Assoziierung ist normalerweise so einfach und ihre Implementierung so an das spezifische Verhalten ihrer Benutzerschnittstellenobjektsklasse gebunden, daß es normalerweise leichter ist, eine neue Assoziierung als eine Unterklasse von EOAssociation zu implementieren, als eine von ihren Unterklassen.

Verfahrenstypen

Synchronisieren von Werten - contentsDidChange
- selectionDidChange
Handhaben von Editierungen - discardEdits
- endEditing

Instanzverfahren

contentsDidChange

- (void)contentsDidChange
Gesendet an eine EOAssociation durch ihre Steuerung, wann immer die Steuerungsobjekte sich geändert haben; zum Beispiel, wenn ein Objekt editiert, eingefügt oder gelöscht wird, oder wenn die Steuerung eine Abrufoperation durchführt. Die Assoziierung sollte bestimmen, ob irgendwelche Werte, für welche sie verantwortlich ist, sich geändert haben, und falls es so ist, sollte sie ihr Benutzerschnittstellenobjekt aktualisieren.
Einer Assoziierung kann sowohl ein contentsDidChange- als auch ein selectionDidChange- Verfahren für eine einzelne Änderung in der Steuerung gesendet werden. Zum Beispiel, falls ein ausgewähltes Objekt gelöscht wird, ändern sich sowohl die Inhalte als auch die Auswahl.

discardEdits

- (void)discardEdits
Ein EOController sendet dieses Verfahren an seine Steuerungen vor dem Abrufen, um sie zu benachrichtigen, daß jegliche editierten Werte, welche Sie für Ihre Benutzerschnittstellenobjekte zwischenspeichern, entledigt werden sollten.

endEditing

- (void)endEditing
Informiert die EOAssociation, daß es formal jegliches Editieren in ihrem Benutzerschnittstellenobjekt beenden soll und informiert die Steuerung von jeglicher schwebender Editierung durch Senden von associationDidEdit. Dies führt normalerweise auch dazu, daß das Benutzerschnittstellenobjekt den ersten Responder niederlegt. Siehe auch: - endEditingFor: (Window-Klasse des ApplicationKit)

selectionDidChange

- (void)selectionDidChange
Gesendet an eine EOAssociation durch ihre Steuerung, wann immer die Steuerungsauswahlindexe sich geändert haben. Die Assoziierung sollte ihre Benutzerschnittstellenobjekte sich wiederanzeigen lassen, um die Änderung in der Auswahl wiederzuspiegeln. Für ein Benutzerschnittstellenobjekt, welches einen Einzelwert anzeigt, setzt die Assoziierung jenen Objektwert auf den Eigenschaftswert für das erste ausgewählte Objekt in der Steuerung. Für ein Benutzerschnittstellenobjekt, welches Mehrfachwerte anzeigt, läßt die Assoziierung das Objekt seine Werte gemäß der Auswahl hervorheben.
Einer Assoziierung kann sowohl ein contentsDidChange- als auch ein selectionDidChange- Verfahren für eine einzelne Änderung in der Steuerung gesendet werden. Zum Beispiel, falls ein ausgewähltes Objekt gelöscht wird, ändern sich sowohl die Inhalte als auch die Auswahl. PSEUDOCODE

Claims

1. In einer objektorientierten Programmierumgebung umfaßt ein Verfahren zum Assoziieren eines Steuerungsobjektes (100), welches eines oder mehrere datentragende Objekte (105a-105f) verwaltet, mit einem oder mehreren Benutzerschnittstellenobjekten (120-160), die Schritte:

Definieren eines ersten Assoziierungsobjektes (210a, 210b, 210c; 220a, 220b; 230a, 230b) für einen ersten Typ von Benutzerschnittstellenobjekt, wobei das erste Assoziierungsobjekt in der Lage ist, Nachrichten, welche spezifisch für den ersten Typ von Benutzerschnittstellenobjekt sind, dem ersten Typ von Benutzerschnittstellenobjekt zu senden und Nachrichten, welche spezifisch für den ersten Typ von Benutzerschnittstellenobjekt sind, von diesem zu empfangen, und ferner in der Lage ist, Standardnachrichten an das Steuerungsobjekt zu senden und von diesem zu empfangen, wobei das erste Assoziierungsobjekt ferner in der Lage ist, einen Datenwert von einem ersten Werttyp, der von einem datentragenden Objekt über das Steuerungsobjekt erhalten wird, in einen zweiten Werttyp zu konvertieren, welcher durch den ersten Typ von Benutzerschnittstellenobjekt dargestellt werden kann;

Erzeugen einer ersten Instanz des ersten Typs von Benutzerschnittstellenobjekt;

Erzeugen einer ersten Instanz des ersten Assoziierungsobjekts;

der ersten Instanz des ersten Assoziierungsobjektes einen Schlüssel zum Erhalten von Daten von einem datentragenden Objekt bereitstellen;

Verknüpfen der ersten Instanz des ersten Assoziierungsobjektes mit der ersten Instanz des ersten Typs von Benutzerschnittstellenobjekt und dem Steuerungsobjekt, derart, daß in Reaktion auf eine Standardnachricht, welche von dem Steuerungsobjekt empfangen wird, die erste Instanz des ersten Assoziierungsobjektes eine Nachricht, welche spezifisch für den ersten Typ von Benutzerschnittstellenobjekt ist, an die erste Instanz des ersten Typs von Benutzerschnittstellenobjekt sendet, und in Reaktion auf einen Empfang einer Nachricht von der ersten Instanz des ersten Typs von Benutzerschnittstellenobjekt, welche spezifisch für den ersten Typ von Benutzerschnittstellenobjekt ist, die erste Instanz des ersten Assoziierungsobjektes eine Standardnachricht an das Steuerungsobjekt sendet.

2. Verfahren nach Anspruch 1, welches ferner die Schritte umfaßt: Definieren eines zweiten Assoziierungsobjektes (210a, 210b, 210c; 220a, 220b; 230a, 230b) für einen zweiten Typ von Benutzerschnittstellenobjekt (120-160), wobei das zweite Assoziierungsobjekt in der Lage ist, Nachrichten, welche spezifisch für den zweiten Typ von Benutzerschnittstellenobjekt sind, an den zweiten Typ von Benutzerschnittstellenobjekt zu senden und Nachrichten, welche typisch für den zweiten Typ von Benutzerschnittstellenobjekt sind, von diesem zu empfangen, und ferner in der Lage ist, Standardnachrichten an das Steuerungsobjekt zu senden und Standardnachrichten von diesem zu empfangen;

Erzeugen einer ersten Instanz des zweiten Typs von Benutzerschnittstellenobjekt;

Erzeugen einer ersten Instanz des zweiten Assoziierungsobjektes;

der ersten Instanz des zweiten Assoziierungsobjektes einen Schlüssel zum Erhalten von Daten aus einem datentragenden Objekt bereitstellen;

Verknüpfen der ersten Instanz des zweiten Assoziierungsobjektes mit der ersten Instanz des zweiten Typs von Benutzerschnittstellenobjekt und dem Steuerungsobjekt, derart, daß in Reaktion auf eine Standardnachricht, welche von dem Steuerungsobjekt empfangen wird, die erste Instanz des zweiten Assoziierungsobjektes eine Nachricht, welche spezifisch für den zweiten Typ von Benutzerschnittstellenobjekt ist, an die erste Instanz des zweiten Typs von Benutzerschnittstellenobjekt sendet, und in Reaktion auf einen Empfang einer Nachricht von der ersten Instanz des zweiten Typs von Benutzerschnittstellenobjekt, welche spezifisch für den zweiten Typ von Benutzerschnittstellenobjekt ist, die erste Instanz des zweiten Assoziierungsobjektes eine Standardnachricht an das Steuerungsobjekt sendet.

3. Verfahren nach Anspruch 1, welches ferner die Schritte aufweist:

Erzeugen einer zweiten Instanz des ersten Typs von Benutzerschnittstellenobjekt;

Erzeugen einer zweiten Instanz des ersten Assoziierungsobjektes;

der zweiten Instanz des ersten Assoziierungsobjektes einen Schlüssel zum Erhalten von Daten aus einem datentragenden Objekt bereitstellen;

Verknüpfen der zweiten Instanz des ersten Assoziierungsobjektes mit der zweiten Instanz des ersten Typs von Benutzerschnittstellenobjekt und dem Steuerungsobjekt derart, daß in Reaktion auf eine Standardnachricht, welche von dem Steuerungsobjekt empfangen wird, die zweite Instanz des ersten Assoziierungsobjektes eine Nachricht, welche spezifisch für den ersten Typ von Benutzerschnittstellenobjekt ist, an die zweite Instanz des ersten Typs von Benutzerschnittstellenobjekt sendet, und in Reaktion auf den Empfang einer Nachricht von der zweiten Instanz des ersten Typs von Benutzerschnittstellenobjekt, welche spezifisch für den ersten Typ von Benutzerschnittstellenobjekt ist, die zweite Instanz des ersten Assoziierungsobjektes eine Standardnachricht an das Steuerungsobjekt sendet.

4. Verfahren nach Anspruch 1, bei welchem die Standardnachrichten, welche durch das Steuerungsobjekt an die Assoziierungsobjekte gesendet werden, eine Nachricht zum Übertragen eines aktuellen Wertes von Daten, welche in einem datentragenden Objekt enthalten sind, umfaßt.

5. Verfahren nach Anspruch 1, bei welchem Standardnachrichten, welche durch das Steuerungsobjekt an Assoziierungsobjekte gesendet werden, eine Nachricht zum Anzeigen umfaßt, daß die Daten, die in einem datentragenden Objekt enthalten sind, sich geändert haben.

6. Verfahren nach Anspruch 1, bei welchem Standardnachrichten, welche durch das Steuerungsobjekt von Assoziierungsobjekten empfangen werden, eine Nachricht zum Anzeigen enthalten, daß ein Datenwert, der in einem Benutzerschnittstellenobjekt angezeigt wird, editiert wurde.

7. Verfahren nach Anspruch 1, bei welchem Standardnachrichten, welche durch das Steuerungsobjekt von Assoziierungsobjekten empfangen werden, eine Nachricht zum Übertragen eines aktuellen Wertes von Daten, welche in einem Benutzerschnittstellenobjekt angezeigt werden, umfaßt.

8. Verfahren nach Anspruch 1, bei welchem Standardnachrichten, welche durch das Steuerungsobjekt an Assoziierungsobjekte gesendet werden, eine Nachricht zum Abfragen eines aktuellen Wertes von Daten, welche in einem Benutzerschnittstellenobjekt angezeigt werden, umfaßt.

9. Verfahren nach Anspruch 1, bei welchem Standardnachrichten, welche von dem Steuerungsobjekt von Assoziierungsobjekten empfangen werden, eine Nachricht zum Abfragen eines aktuellen Wertes von Daten, welche in einem datentragenden Objekt enthalten sind, umfaßt.

10. Verfahren nach Anspruch 9, bei welchem Daten in einem datentragenden Objekt in Form eines Schlüsselwertpaares gespeichert werden, und wobei die Nachricht zum Abfragen eines aktuellen Wertes von Daten, die in einem datentragenden Objekt enthalten sind, den an das Assoziierungsobjekt bereitgestellten Schlüssel enthält.

11. Verfahren nach Anspruch 8, bei welchem Daten in dem Benutzerschnittstellenobjekt in Form eines Schlüsselwertpaares gespeichert werden, und die Nachricht zum Abfragen eines aktuellen Wertes von Daten, welche durch ein datentragendes Objekt angezeigt werden, einen Schlüssel zum Identifizieren von Daten, welche in dem Benutzerschnittstellenobjekt enthalten sind, umfaßt.

12. Verfahren zum Anzeigen von Daten, welche in datentragenden Objekten (105a-105f) enthalten sind, an einer Benutzerschnittstelle (110) in einer objektorientierten Programmierumgebung, mit den Schritten:

Bereitstellen eines Steuerungsobjektes (100) zum Verwalten einer Vielzahl von datentragenden Objekten;

Bereitstellen einer Vielzahl von Typen von Benutzerschnittstellenobjekten (120-160) zum Anzeigen von Daten an einer Benutzerschnittstelle;

für jeden Typ von Benutzerschnittstellenobjekt Bereitstellen eines entsprechenden Assoziierungsobjektes (210a, 210b, 210c; 220a, 220b; 230a, 230b), welches in der Lage ist, Nachrichten, welche spezifisch für den Typ von Benutzerschnittstellenobjekt sind, an den Typ von Benutzerschnittstellenobjekt zu senden und Nachrichten, welche spezifisch für den Typ von Benutzerschnittstellenobjekt sind, von diesem zu empfangen, und ferner in der Lage ist, Standardnachrichten an das Steuerungsobjekt zu senden und Standardnachrichten von diesem zu empfangen, wobei die Assoziierungsobjekte ferner in der Lage sind, einen Datenwert von einem ersten Werttyp, der von einem datentragenden Objekt über das Steuerungsobjekt erhalten wird, in einen zweiten Werttyp zu konvertieren, welcher durch den Typ von Benutzerschnittstellenobjekt angezeigt werden kann;

Bereitstellen von Mitteln zum Erzeugen einer Instanz eines Assoziierungsobjektes mit einem Schlüssel zum Erhalten von Daten aus einem datentragenden Objekt;

Bereitstellen von Mitteln zum Verknüpfen einer Instanz eines Assoziierungsobjektes mit einer Instanz eines entsprechenden Typs von Benutzerschnittstellenobjekt und einem Steuerungsobjekt, derart, daß in Reaktion auf eine Standardnachricht, welche von dem Steuerungsobjekt empfangen wird, die Instanz des Assoziierungsobjektes eine Nachricht, welche spezifisch für den entsprechenden Typ von Benutzerschnittstellenobjekt ist, an die Instanz des entsprechenden Typs von Benutzerschnittstellenobjekt sendet, und in Reaktion auf einen Empfang einer Nachricht von der Instanz eines entsprechenden Typs von Benutzerschnittstellenobjekt, welche spezifisch für den entsprechenden Typ von Benutzerschnittstellenobjekt ist, die Instanz des Assoziierungsobjektes eine Standardnachricht an das Steuerungsobjekt sendet.

13. Verfahren nach Anspruch 12, bei welchem Standardnachrichten, welche durch das Steuerungsobjekt an Assoziierungsobjekte gesendet werden, eine Nachricht zum Übertragen eines aktuellen Wertes von Daten, welche in einem datentragenden Objekt enthalten sind, umfaßt.

14. Verfahren nach Anspruch 12, bei welchem Standardnachrichten, welche durch das Steuerungsobjekt an Assoziierungsobjekte gesendet werden, eine Nachricht zum Anzeigen umfaßt, daß die Daten, die in einem datentragenden Objekt enthalten sind, sich geändert haben.

15. Verfahren nach Anspruch 12, bei welchem Standardnachrichten, welche durch das Steuerungsobjekt von Assoziierungsobjekten empfangen werden, eine Nachricht zum Anzeigen enthalten, daß ein Datenwert, der in einem Benutzerschnittstellenobjekt angezeigt wird, editiert wurde.

16. Verfahren nach Anspruch 12, bei welchem Standardnachrichten, welche durch das Steuerungsobjekt von Assoziierungsobjekten empfangen werden, eine Nachricht zum Übertragen eines aktuellen Wertes von Daten, welche in einem Benutzerschnittstellenobjekt angezeigt werden, umfaßt.

17. Verfahren nach Anspruch 12, bei welchem Standardnachrichten, welche durch das Steuerungsobjekt an Assoziierungsobjekte gesendet werden, eine Nachricht zum Abfragen eines aktuellen Wertes von Daten, welche in einem Benutzerschnittstellenobjekt angezeigt werden, umfaßt.

18. Verfahren nach Anspruch 12, bei welchem Standardnachrichten, welche von dem Steuerungsobjekt von Assoziierungsobjekten empfangen werden, eine Nachricht zum Abfragen eines aktuellen Wertes von Daten, welche in einem datentragenden Objekt enthalten sind, umfaßt.

19. Verfahren nach Anspruch 18, bei welchem Daten in einem datentragenden Objekt in Form eines Schlüsselwertpaares gespeichert werden, und die Nachricht zum Abfragen eines aktuellen Wertes von Daten, die in einem datentragenden Objekt enthalten sind, einen Schlüssel zum Identifizieren der Daten, die in dem datentragenden Objekt enthalten sind, enthält.

20. Verfahren nach 17, bei welchem Daten in dem Benutzerschnittstellenobjekt in Form eines Schlüsselwertpaares gespeichert werden, und die Nachricht zum Abfragen eines aktuellen Wertes von Daten, welche durch ein datentragendes Objekt angezeigt werden, einen Schlüssel zum Identifizieren von Daten, welche in dem Benutzerschnittstellenobjekt enthalten sind, umfaßt.

21. Verfahren nach 12, bei welchem die Vielzahl von Typen von Benutzerschnittstellenobjekten einen Tabellenspalten-Typ eines. Benutzerschnittstellenobjektes umfaßt.