Войти
События 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 с типом список(список или массив). Их внутренняя структура содержит рекурсивно-вложенные 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 (AEOM ) представляла собой набор протоколов, построенных на основе AppleEvents, с помощью которых приложения, работающие на классическом Mac ОС и macOS могут управлять функциями друг друга. Приложения, реализующие некоторую часть AEOM, назывались поддерживающими сценарии, потому что ими можно было управлять с помощью AppleScript. К сожалению, на протяжении всей истории классической Mac OS поддержка сценариев оставалась неоднородной и непоследовательной.
AEOM предоставляет синтаксический уровень, под которым любое приложение может публиковать свои внутренние объекты, позволяя управлять этими объектами стандартизированным способом. В отличие от других схожих по звучанию концепций, таких как ToolTalk, существительные и глаголы четко различались по ортогональности; таким образом, вместо предоставления отдельных команд для «закрыть документ» и «закрыть окно», существовала одна команда «закрыть», которая могла принимать ссылки на объекты «документ» или «окно» или любой другой объект, опубликованный приложением.
Объекты, которые приложение сделало доступными благодаря поддержке AEOM, были организованы в иерархию. Вверху было само приложение, на которое ссылался дескриптор нулевого объекта. На другие объекты ссылались (рекурсивно) путем указания их родительского объекта вместе с другой информацией, идентифицирующей его как дочерний по отношению к этому родительскому объекту, и все они собраны в AERecord. Родители предоставили итератор для перечисления своих дочерних элементов или дочерних элементов определенного класса, что позволяет приложениям обращаться к набору элементов. Система в целом была похожа на объектную модель документа, используемую в XML, хотя с некоторыми отличиями в шаблонах доступа.
Каждый объект может иметь элементы и свойства; элементы - это другие объекты, которые могут быть созданы или удалены, в то время как свойства не могут быть созданы или удалены, но имеют значения, которые можно запросить или изменить. Например, приложение может иметь один или несколько оконных элементов, представляющих окна, отображающие содержимое открытых в данный момент документов. Эти окна могут иметь такие свойства, как заголовок, положение и размер.
Приложение может определять пользовательские команды для работы со своими объектами. В AEOM также указаны различные стандартные команды, которые (как предполагалось) приложения будут реализовывать согласованным образом, например, открыть, закрыть, создать элемент, удалить, установить данные и получить данные. Каждый глагол был определен как событие AppleEvent определенного типа и класса вместе с определенными параметрами определенных типов, которые должны были присутствовать. Например, событие «получить данные» было стандартным средством для получения значения свойства: требовалось, по существу, один параметр, который представлял собой дескриптор объекта, идентифицирующий запрашиваемое свойство. Значение этого свойства будет возвращено в событии ответа. Событие «set data» принимает два параметра: дескриптор объекта для свойства, которое нужно установить, и новое значение для свойства; ожидалось, что событие ответа вернет только статус успеха или код ошибки сбоя.
Вся архитектура AppleEvent идентифицирует объекты с помощью четырехбайтовых кодов OSType, старательно избегая реальных слов или фраз на английском (или любом другом языке). Вместо этого соответствие между внутренними кодами AppleEvent и внешними описаниями на естественном языке указывается через ресурс aete (расширение терминологии AppleEvent) - «расширение» относится к стандартной терминологии, встроенной в AppleScript. сам. Приложение может предоставлять несколько ресурсов «aete» для нескольких языков в соответствии с исходным многоязычным дизайном самого AppleScript
Например, рассмотрим следующую последовательность AppleScript, управляющую вымышленным приложением для рисования:
сообщите приложению «ScriptableDraw «установить цвет фона окна« Новый рисунок »на цвет фона окна« Старый рисунок »end tell
Фактически это включает отправку двух событий AppleEvents целевому приложению (и получение их соответствующих ответов): во-первых, получение -data событие отправляется для получения свойства цвета фона окна, идентифицированного именем «Старый чертеж»; затем отправляется событие набора данных для применения значения, возвращенного как свойство цвета фона окна с именем «Новый чертеж».
Так как такой вид шаблона доступа был типичным, AppleScript широко использовал оператор tell, который переключает контекст на названный объект аналогично с, найденный в Visual Basic или Pascal. Все команды после tellдо соответствующего end tellбудут отправлены объекту, указанному в tell, вместо объекта по умолчанию, которым было текущее приложение..
Дескрипторы объектов позволяли идентифицировать объекты различными способами. Самым интересным было использование предложения where (которое переведено в терминологию AppleScript как выражение фильтра). Например, AppleScript 1.0 SDK поставлялся с исходным кодом для примера приложения под названием Scriptable Text Editor, которое будет реагировать на такие скрипты, как:
tell application «Scriptable Text Editor» окно сообщения «Пример Документ »устанавливает стиль текста для каждого слова, длина которого>7 до полужирного конца tell end tell
Даже сегодня редко можно найти такую мощь в языках сценариев общего назначения за пределами SQL.
Добавление поддержки для AEOM в классической Mac OS был трудным процессом. Разработчики приложений должны были идентифицировать свои объекты и вручную писать код, чтобы их можно было решить. Обычно это принимало форму кода для возврата «следующего» объекта определенного типа, что позволяло AppleScript выполнять итерацию по ним. Но поскольку ОС не содержала объектной модели, эта работа была полностью оставлена разработчикам, многие из которых не реализовали ее. Как ни странно, даже собственный каркас приложений Apple, MacApp не предлагал такой модели, за исключением объектов GUI, о которых он знал, что снова заставляло разработчика делать больше всего. работы по написанию сценариев объектов, представляющих сами данные. Во многом по этим причинам поддержка AppleScript не получила широкого распространения.
Apple действительно попыталась решить эту проблему, введя различные «наборы» объектов, которые представляли стандартные объекты и команды, которые, как ожидается, будут поддерживаться различными типами приложений. Например, ожидалось, что все приложения будут поддерживать «основной набор», а любой текст для редактирования приложения должен поддерживать «набор текстов». Выбрав подходящий набор наборов, разработчик мог, по крайней мере, уменьшить рабочую нагрузку по планированию того, как раскрыть свои объекты. Тем не менее, поскольку эти объекты, как правило, не были частью самой системы (за исключением сильно ограниченного редактора TextEdit), фактическая реализация оставалась на усмотрение разработчика.
Приложения, разработанные в Какао, системе, ранее известной как OpenStep, предлагают среду выполнения с богатыми объектами, которые можно запрашивать из любого другого приложения. Это значительно упрощает реализацию AEOM, резко сокращая объем кода, необходимого для среднего приложения. Кроме того, большинство приложений Какао построено в основном из стандартных объектов Какао, все из которых были обновлены, чтобы предлагать достаточно широкие возможности сценариев. Это распространяется не только на объекты графического интерфейса, как в MacApp, но и на объекты данных внутри них, включая текст, таблицы и различные объекты списков. Текстовый файл используется для сопоставления внутренних "объектных" имен с удобочитаемыми версиями, и в большинстве случаев создание этого файла - это все, что необходимо для добавления значительной возможности сценариев в большинство программ.
В то время как приложения Какао не основаны на AEOM и часто используют объекты, слегка отличающиеся от первоначально определенных стандартных объектов Apple, приложения Какао, как правило, гораздо более подвержены сценариям, чем их «классические» аналоги - на самом деле, редко можно найти Приложение какао, которое в некоторой степени не поддерживает сценарии.
