Событие Apple

События Apple - это механизм межпроцессного взаимодействия на основе сообщений в Mac OS , впервые появившийся в System 7 и с тех пор поддерживаемый всеми версиями классической Mac OS и macOS . События Apple описывают «высокоуровневые» события, такие как «открыть документ» или «файл печати», тогда как более ранние ОС поддерживали гораздо более простые события, а именно «щелчок» и «нажатие клавиши». События Apple составляют основу системы сценариев Mac OS, Open Scripting Architecture (основным языком для нее является AppleScript ).

Отправной точкой является динамически типизированный расширяемый формат дескриптора, называемый AEDesc , который представляет собой просто код OSType, определяющий тип данных вместе с блоком данных, зависящих от типа. Например, код OSType inteуказывает, что данные представляют собой четырехбайтовое целое число со знаком в формате big-endian .

Помимо предопределенных кодов типов для различных распространенных простых типов, существует два предопределенных типа структурированных дескрипторов: AERecord , который имеет тип данных reco(запись), и AEList с типом list(список или массив). Их внутренняя структура содержит рекурсивно вложенные AEDesc, в то время как AERecord также связывает каждый элемент с уникальным идентификатором поля записи, который является OSType. Apple Event Manager предоставляет вызовы API для создания этих структур, а также для извлечения их содержимого и запроса типа содержимого, которое они содержат.

Apple Event Manager также поддерживает принуждение , которое преобразует AEDesc из одного типа данных в другой. В дополнение к стандартным приведениям, например между целочисленными и действительными типами, приложения могут устанавливать свои собственные обратные вызовы обработчиков принуждения , которые обрабатывают преобразования в пользовательские типы данных и из них.

Apple , событие собственно является AERecord с полями , которые зависят от цели мероприятия. Кроме того, он имеет атрибуты (которые отличаются от полей записи, которые теперь называются параметрами события) из набора, предопределенного Apple Event Manager. Они указывают , что событие должно делать (через класс событий и идентификатор события ), целевой адрес , по которому событие должно быть отправлено (который может быть процессом на локальном или удаленном компьютере), а также различные другие варианты обработки Это. Первоначально удаленные машины должны были быть подключены через AppleTalk , но Mac OS 9 добавила возможность подключения через TCP / IP .

После отправки события Apple целевому процессу отправляющий процесс может выбрать получение ответного события Apple. Он может содержать различные биты информации, возвращаемой от цели об обработке исходного события, включая код ошибки, указывающий на успех / неудачу, любую информацию, запрошенную исходным событием, и / или другую соответствующую информацию.

События Apple являются основой объектной модели AppleEvent , которая, в свою очередь, является основой OSA и AppleScript . По состоянию на 2016 год ^{[Обновить]}официальная реализация API Apple Event Manager доступна на C и его потомках, включая C ++ . Официальные привязки также предоставляются для Objective-C и Swift через Cocoa API . Неофициальные привязки также существуют для других языков (с различной степенью ограничения), включая Perl , UserTalk , Ruby и Python .

Объектная модель [ править ]

AppleEvent Object Model ( AEOM ) представляла собой набор протоколов , построенных на вершине AppleEvent с помощью которого приложения , работающих под управлением классической Mac OS и MacOS может управлять функциями друг друга. Приложения, реализующие некоторую часть AEOM, назывались скриптовыми, потому что ими можно было управлять через AppleScript . К сожалению, на протяжении всей истории классической Mac OS поддержка сценариев оставалась неоднородной и непоследовательной.

AEOM предоставляет синтаксический уровень, под которым любое приложение может публиковать свои внутренние объекты, позволяя управлять этими объектами стандартизованным способом. В отличие от других похожих по звучанию концепций, таких как ToolTalk , существительные и глаголы четко различались по ортогональности ; таким образом, вместо предоставления отдельных команд для «закрыть документ» и «закрыть окно» существовала одна команда «закрыть», которая могла принимать ссылки на объекты «документ» или «окно» или любой другой объект, опубликованный приложением.

Объекты, которые приложение сделало доступными благодаря поддержке AEOM, были организованы в иерархию. Наверху было само приложение, на которое ссылался дескриптор нулевого объекта. На другие объекты ссылались (рекурсивно) путем указания их родительского объекта вместе с другой информацией, идентифицирующей его как дочерний по отношению к этому родительскому объекту , и все это было собрано в AERecord . Итератор был предоставлен родителям , чтобы перечислить их детей, или детей определенного класса, позволяя приложениям обращаться набор элементов. Система в целом была похожа на объектную модель документа, используемую в XML , хотя и с некоторыми отличиями в шаблонах доступа.

У каждого объекта могут быть элементы и свойства ; элементы - это другие объекты, которые могут быть созданы или удалены, в то время как свойства не могут быть созданы или удалены, но имеют значения, которые можно запросить или изменить. Например, приложение может иметь один или несколько оконных элементов, представляющих окна, показывающие содержимое открытых в данный момент документов. Эти окна могут иметь такие свойства , как заголовок, положение и размер.

Приложение может определять пользовательские команды для работы со своими объектами. AEOM также определил различные стандартные команды, которые (как надеялись) приложения будут реализовывать согласованным образом, такие как открыть, закрыть, создать элемент, удалить, установить данные и получить данные. Каждый глагол был определен как событие AppleEvent определенного типа и класса вместе с определенными параметрами определенных типов, которые должны были присутствовать. Например, событие «получить данные» было стандартным средством для получения значения свойства: требовалось, по существу, один параметр, который представлял собой дескриптор объекта, идентифицирующий запрашиваемое свойство. Значение этого свойства будет возвращено в событии ответа. Событие «set data» принимает два параметра: дескриптор объекта для свойства, которое нужно установить, и новое значение для свойства;ожидалось, что событие ответа вернет только статус успеха или код ошибки сбоя.

Вся архитектура AppleEvent идентифицирует вещи с помощью четырехбайтовых кодов OSType , старательно избегая реальных слов или фраз на английском (или любом другом языке). Вместо того , соответствие между внутренними кодами AppleEvent и внешними описаниями на естественном языке задается через aete ( AppleEvent Терминология Расширение ) ресурсы - на «расширение» быть стандартной терминологии , встроенной в самой AppleScript. Приложение может предоставлять несколько ресурсов aete для нескольких языков в соответствии с оригинальным многоязычным дизайном самого AppleScript.

Например, рассмотрим следующую последовательность AppleScript, управляющую вымышленным приложением для рисования:

 скажите  приложение  «ScriptableDraw»  набор  цвет фона  в  окне  «Новый чертеж» ,  чтобы  цвет фона  в  окне  «Старый чертеж»  конец  Телль

Фактически это включает в себя отправку двух событий AppleEvents целевому приложению (и получение их соответствующих ответов): сначала отправляется событие получения данных для извлечения свойства цвета фона окна, идентифицированного именем «Старый чертеж»; затем отправляется событие набора данных для применения значения, возвращенного как свойство цвета фона окна с именем «Новый чертеж».

Поскольку этот вид шаблона доступа был типичным, AppleScript широко использовал tellоператор, который переключает контекст на именованный объект аналогично withоператору в Visual Basic или Pascal . Все команды после tellсоответствующих end tellбудут отправлены объекту, указанному в tell, вместо объекта по умолчанию, которым было текущее приложение.

Дескрипторы объектов позволяли идентифицировать объекты различными способами. Самым интересным было использование предложения where (которое переведено в терминологию AppleScript как выражение фильтра ). Например, AppleScript 1.0 SDK поставляется с исходным кодом для примера приложения под названием Scriptable Text Editor, которое будет реагировать на такие сценарии, как:

 скажите  приложение  «Scriptable Text Editor»  Телль  окно  «Пример документа»  набор  текста  стиль  из  каждого  слова  которого  длина  >  7  до  полужирный  конца  Телль  конца  рассказывают

Даже сегодня редко можно найти такую ​​мощь в языках сценариев общего назначения вне SQL .

Добавление поддержки AEOM в классическую Mac OS было трудным процессом. Разработчики приложений должны были идентифицировать свои объекты и вручную писать код, чтобы их можно было решить. Обычно это принимало форму кода для возврата «следующего» объекта определенного типа, что позволяло AppleScript выполнять итерацию по ним. Но поскольку ОС не содержала объектной модели, эта работа была полностью оставлена ​​разработчикам, многие из которых не реализовали ее. Как ни странно, даже собственный фреймворк Apple , MacApp , не предлагал такой модели, за исключением графического интерфейса.объекты, о которых он знал, снова заставляя разработчика выполнять большую часть работы по написанию сценариев для объектов, представляющих сами данные. Во многом по этим причинам поддержка AppleScript не получила широкого распространения.

Apple действительно попыталась решить эту проблему, введя различные «наборы» объектов, которые представляли стандартные объекты и команды, которые, как ожидается, будут поддерживаться различными типами приложений. Например, ожидалось, что все приложения будут поддерживать «основной набор», а любой текст для редактирования приложений должен поддерживать «набор текстов». Выбрав подходящий набор наборов, разработчик мог, по крайней мере, уменьшить рабочую нагрузку по планированию того, как раскрыть свои объекты. Тем не менее, поскольку эти объекты обычно не были частью самой системы (за исключением сильно ограниченного редактора TextEdit), фактическая реализация оставалась на усмотрение разработчика.

Приложения, разработанные в Cocoa , системе, ранее известной как OpenStep , предлагают богатую среду выполнения объектов, которую можно запрашивать из любого другого приложения. Это значительно упрощает реализацию AEOM, резко сокращая объем кода, необходимого для среднего приложения. Кроме того, большинство приложений Какао построено в основном из стандартных объектов Какао, все из которых были обновлены, чтобы предлагать достаточно широкие возможности сценариев. Это распространяется не только на объекты графического интерфейса, как в MacApp, но и на объекты данных внутри них, включая текст, таблицы и различные объекты списков. Текстовый файл используется для сопоставления внутренних "объектных" имен с удобочитаемыми версий, и в большинстве случаев их создание - это все, что нужно для добавления довольно значительной возможности сценариев в большинство программ.

В то время как приложения Какао не основаны на AEOM и часто используют объекты, слегка отличающиеся от первоначально определенных стандартных объектов Apple, приложения Какао, как правило, гораздо более подвержены сценариям, чем их «классические» аналоги - на самом деле, редко можно найти приложение Какао, которое не поддерживает сценарии. до некоторой степени.

Дальнейшее чтение [ править ]

• Кук, Уильям Р. (29 сентября 2006 г.), AppleScript (PDF) , Техасский университет в Остине, стр. 1–1–1–21, CiteSeerX  10.1.1.76.6993 , doi : 10.1145 / 1238844.1238845 , получено 9 мая, 2009 г.. В частности, см. Раздел 2.3 «События Apple» (страницы 9–13), хотя история и важность событий Apple также обсуждаются в другом месте документа.

Внешние ссылки [ править ]

• appscript - мост событий Apple для Python, Ruby и Objective-C