Das AppleEvent-Objektmodell ( AEOM ) war eine Reihe von Protokollen, die auf AppleEvents aufbauen, mit denen Anwendungen, die unter klassischem Mac OS und macOS ausgeführt werden, die Funktionen des jeweils anderen steuern können. Anwendungen, die einen Teil der AEOM implementierten, wurden als scriptable bezeichnet, da sie über AppleScript gesteuert werden konnten. Leider blieb die Skriptfähigkeitsunterstützung in der Geschichte des klassischen Mac OS lückenhaft und inkonsistent.

Die AEOM stellte eine syntaktische Ebene bereit, unter der jede Anwendung ihre internen Objekte veröffentlichen konnte, sodass diese Objekte auf standardisierte Weise bearbeitet werden konnten. Im Gegensatz zu anderen ähnlich klingenden Konzepten wie ToolTalk gab es eine klare, orthogonale Unterscheidung zwischen Substantiven und Verben ; Anstatt also separate Befehle für "Dokument schließen" und "Fenster schließen" bereitzustellen, gab es ein einzelnes Verb "Schließen", das Verweise auf "Dokument" – oder "Fenster" -Objekte oder jedes andere von der Anwendung veröffentlichte Objekt enthalten konnte.

Die Objekte, die eine Anwendung über ihre AEOM-Unterstützung zur Verfügung stellte, wurden in einer Hierarchie angeordnet. Oben befand sich die Anwendung selbst, auf die über einen Null-Objektdeskriptor verwiesen wurde. Auf andere Objekte wurde verwiesen, indem (rekursiv) das übergeordnete Objekt zusammen mit anderen Informationen, die es als untergeordnetes Objekt dieses übergeordneten Objekts identifizierten, in einem AERecord gesammelt wurden. Ein -Iterator wurde von den Eltern bereitgestellt, um ihre Kinder oder Kinder einer bestimmten Klasse aufzulisten, sodass Anwendungen eine Reihe von Elementen ansprechen können. Das System ähnelte im Allgemeinen dem in XML verwendeten Dokumentobjektmodell, allerdings mit einigen Unterschieden bei den Zugriffsmustern.

Jedes Objekt könnte Elemente und Eigenschaften haben; Elemente waren andere Objekte, die erstellt oder gelöscht werden konnten, während Eigenschaften nicht erstellt oder gelöscht werden konnten, sondern Werte hatten, die abgefragt oder geändert werden konnten. Beispielsweise kann die Anwendung ein oder mehrere Fensterelemente aufweisen, die Fenster darstellen, die den Inhalt der aktuell geöffneten Dokumente anzeigen. Diese Fenster können Eigenschaften wie Titel, Position und Größe haben.

Eine Anwendung könnte benutzerdefinierte Verben für die Bearbeitung ihrer Objekte definieren. Die AEOM spezifizierte auch verschiedene Standardverben, die (wie erhofft war) von Anwendungen konsistent implementiert wurden, z. B. Öffnen, Schließen, Erstellen von Elementen, Löschen, Festlegen von Daten und Abrufen von Daten. Jedes Verb wurde als AppleEvent eines bestimmten Typs und einer bestimmten Klasse definiert, zusammen mit bestimmten Parametern bestimmter Typen, von denen erwartet wurde, dass sie vorhanden sind. Beispielsweise war das Ereignis "Daten abrufen" das Standardmittel zum Abrufen des Werts einer Eigenschaft: Es benötigte im Wesentlichen einen Parameter, der ein Objektdeskriptor war, der die abzufragende Eigenschaft identifiziert. Der Wert dieser Eigenschaft wird im Antwortereignis zurückgegeben. Das Ereignis "set data" nahm zwei Parameter an, den Objektdeskriptor für die festzulegende Eigenschaft und den neuen Wert für die Eigenschaft. Es wurde nur erwartet, dass das Antwortereignis einen Erfolgsstatus oder einen Fehlercode zurückgibt.

Die gesamte AppleEvent-Architektur identifiziert Dinge mithilfe von 4-Byte-OSType-Codes, wobei tatsächliche Wörter oder Ausdrücke in Englisch (oder einer anderen Sprache) sorgfältig vermieden werden. Stattdessen wird die Entsprechung zwischen internen AppleEvent-Codes und externen Beschreibungen in natürlicher Sprache über die Ressource "aete ( AppleEvent-Terminologieerweiterung )" spezifiziert. Die "Erweiterung" entspricht der in AppleScript integrierten Standardterminologie selbst. Eine Anwendung kann mehrere 'Aete'-Ressourcen für mehrere Sprachen bereitstellen, die dem ursprünglichen mehrsprachigen Design von AppleScript selbst entsprechen

Betrachten Sie beispielsweise die folgende AppleScript-Sequenz, die eine Anwendung für fiktives Zeichnen steuert:

  Anwendung   "ScriptableDraw" 
    festlegen   Hintergrundfarbe   von   Fenster   "Neue Zeichnung"   bis   Hintergrundfarbe   of   window   "Old Drawing" 
  end   tell 

Hierbei werden tatsächlich zwei AppleEvents an die Zielanwendung gesendet (und die entsprechenden Antworten empfangen): Datenereignis wird gesendet, um die Hintergrundfarbeigenschaft des Fensters abzurufen, das durch den Namen "Alte Zeichnung" identifiziert wird; Anschließend wird ein Set-Data-Ereignis gesendet, um den als Hintergrundfarbeigenschaft des Fensters mit dem Namen "Neue Zeichnung" zurückgegebenen Wert anzuwenden.

Da diese Art von Zugriffsmuster typisch ist, hat AppleScript die Anweisung tell in großem Umfang verwendet, mit der der Kontext zum benannten Objekt auf ähnliche Weise wie die Anweisung mit der Anweisung geändert wurde in Visual Basic oder Pascal. Alle Befehle nach dem tell zum entsprechenden tell werden an das im tell angegebene Objekt gesendet, anstelle des Standardobjekts, bei dem es sich um die aktuelle Anwendung handelt .

Objektdeskriptoren ermöglichten die Identifizierung von Objekten auf verschiedene Arten. Am interessantesten war die Verwendung einer Where-Klausel (die in die AppleScript-Terminologie als Filterausdruck übersetzt wurde). Beispielsweise wurde das AppleScript 1.0 SDK mit dem Quellcode für eine Beispielanwendung namens Scriptable Text Editor ausgeliefert, die auf Skripte wie die folgenden reagiert:

  tell   application   "Scriptable Text Editor" 
    tell   window   "Example Document" 
      set   text   style   of   Jedes   Wort  dessen   Länge  >   7   bis   fett 
    Ende   und 
  Ende   bis heute , Es ist selten, dass diese Art von Macht in Allzweck-Skriptsprachen außerhalb von SQL zu finden ist.
 Das Hinzufügen der Unterstützung für AEOM unter dem klassischen Mac OS war ein schwieriger Prozess. Anwendungsentwickler mussten ihre Objekte identifizieren und Code von Hand schreiben, damit sie angesprochen werden konnten. Dies erfolgte normalerweise in Form von Code, um das "nächste" Objekt eines bestimmten Typs zurückzugeben, sodass AppleScript sie durchlaufen kann. Da das Betriebssystem jedoch kein Objektmodell enthielt, wurde diese Arbeit ausschließlich den Entwicklern überlassen, von denen viele es nicht implementierten. Seltsamerweise bot selbst Apples eigenes Anwendungsframework, MacApp, ein solches Modell mit Ausnahme der ihm bekannten GUI-Objekte nicht an, so dass der Entwickler erneut den größten Teil der Arbeit für die Skripterstellung der Objekte erledigte, die die Daten selbst repräsentierten. Vor allem aus diesen Gründen war die AppleScript-Unterstützung nicht sehr verbreitet.
 Apple hat versucht, dieses Problem mit der Einführung verschiedener Objekt- "Suites" zu lösen, die Standardobjekte und -verben darstellten, von denen erwartet wurde, dass sie von verschiedenen Anwendungstypen unterstützt werden. Beispielsweise wurde erwartet, dass alle Anwendungen die "Kernsuite" unterstützen, und jeder Text zur Bearbeitung von Anwendungen sollte die "Textsuite" unterstützen. Durch die Auswahl geeigneter Suiten könnte der Entwickler zumindest den Planungsaufwand für die Belichtung seiner Objekte verringern. Da diese Objekte jedoch im Allgemeinen nicht Teil des Systems selbst waren (mit Ausnahme des stark eingeschränkten TextEdit-Editors), wurde die eigentliche Implementierung dem Entwickler überlassen.
 In Cocoa, dem früheren OpenStep-System, entwickelte Anwendungen bieten eine umfangreiche Objektlaufzeit, die von jeder anderen Anwendung abgefragt werden kann. Dies erleichtert die Implementierung der AEOM erheblich und reduziert die in einer durchschnittlichen Anwendung benötigte Codemenge erheblich. Darüber hinaus werden die meisten Cocoa-Anwendungen hauptsächlich aus Cocoa-Standardobjekten erstellt, die alle aktualisiert wurden, um eine ziemlich umfassende Skriptfähigkeit zu bieten. Dies erstreckt sich nicht nur auf GUI-Objekte wie unter MacApp, sondern auch auf Datenobjekte, einschließlich Text, Tabellen und verschiedener Listenobjekte. Eine Textdatei wird verwendet, um die internen "objektähnlichen" Namen lesbaren Versionen zuzuordnen, und in den meisten Fällen ist dies alles, was erforderlich ist, um den meisten Programmen eine ziemlich umfassende Skriptfähigkeit zu verleihen.
 Während Cocoa-Anwendungen nicht AEOM-basiert sind und häufig subtil andere Objekte als Apples ursprünglich definierte Standardobjekte verwenden, sind Cocoa-Apps in der Regel viel besser skriptfähig als ihre "klassischen" Gegenstücke - tatsächlich ist es selten, eine Cocoa-Anwendung zu finden, die diese verwendet ist  bis zu einem gewissen Grad nicht  skriptfähig.

 Referenzen  [ bearbeiten ]