Техническое примечание TN2106

Сценарии интерфейсных инструкций

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

Введение Основы Стиль Общие указания. Выбор элементов языка Именование правил Стиль комментария Объекты Разработка Ваших объектов Объектные спецификаторы Стандартные классы Стандартные свойства Команды Разработка Ваших команд Стандартные команды Сценарии представления Сценарии Windows Сценарии выбора Общие советы Подсказки для Использования сценариев какао Ссылки История версии документа

Введение

Почему существуют эти инструкции?

Эти инструкции служат подобной цели к Инструкциям по Интерфейсу пользователя: продвинуть принципы базовой конструкции и непротиворечивость в интерфейсе сценариев всех приложений Macintosh. Принципы разработки - все о том, чтобы быть специфичным для задачи; чем более близко Вы соответствуете умственную модель пользователя своего приложения, тем более полезный это будет. Непротиворечивость в интерфейсе сценариев ценна по тем же причинам, это находится в регулярном интерфейсе: это упрощает для пользователей изучать новые приложения и уменьшает возможности, что они сделают ошибки следующими старыми привычками, который поочередно сокращает количество обращений за поддержкой, которые Вы будете иметь к полю. Кроме того, непротиворечивость среди приложений продвигает AppleScript как последовательную систему, не только тонкий бит связующего звена, скрепляющего мешанину того, что является практически различными языками.

Следующим эти инструкции можно сделать пользователей более счастливыми, собственная проще жизнь, и справка продвигает AppleScript как полезный инструмент.

Назад к началу.

Что пишет сценарий?

Сценарии программируют использование языка сценариев. Это не было очень полезно: что такое язык сценариев? Язык сценариев является специфичным для задачи языком программирования, в противоположность системному языку программирования, такому как C, C++ или Java. Системные языки программирования разработаны для создавания приложений с нуля и являются очень общей целью – можно создать что-либо, но также необходимо создать все, часто из очень маленьких частей. Языки сценариев, с другой стороны, разработаны с определенной задачей в памяти. Они могут выразить вещи, надлежащие задаче очень легко, но являются неловкими или даже отключают звук по другим вопросам. Например, awk очень хорошо в управлении колоночным текстом, и ActionScript очень хорош в мультимедиа, но Вы не хотели бы использовать любого из них для финансовой отчетности.

Быть специфичным для задачи является хорошей вещью по нескольким причинам. Мало того, что это позволяет, Вы записать меньше кода, но и людей делают намного лучше в познавательных задачах (как программирование), когда содержание установлено в знакомом домене. Поэтому издатель, который изумлен указателями и укусил арифметику, все еще будет в состоянии записать сложный сценарий, работающий с точки зрения текстовых потоков и иллюстраций.

При размышлении о том, что специфично для задачи, полезно рассмотреть не только, что задача, но также и каково это не. Например, издатель выше обеспокоен измерениями поля и кернингом, но не хочет быть обеспокоенным управлением памятью или объявлением тип переменных. Соответственно, языки сценариев имеют тенденцию выделять и освобождать память автоматически, не требовать тип переменных, и обычно заботиться о большом количестве подробных данных, с которыми системный язык программирования потребовал бы, чтобы Вы имели дело.

Весь этот фокус и удобство прибывают в стоимость, конечно: некоторые языки сценариев являются дико несоответствующими для некоторых проблем и программ, записанных на языке сценариев, обычно выполняемом медленнее, чем эквивалентный, записанный в системном языке программирования. С другой стороны, сценарист не мог бы быть в состоянии записать более быструю версию вообще или не мог бы просто иметь времени, и незаписанная программа работает только с такой скоростью, как человек может сделать задачу вручную.

Для дополнительного взятия на этом предмете см., что статья Джона Устерхута Пишет сценарий: Высокоуровневое Программирование в течение 21-го века.

Назад к началу.

Что такое scriptability?

Scriptability является возможностью Вашего приложения, которым будет управлять сценарий – т.е. программа – а не лицо, вооруженное клавиатурой и мышью. Путем подавания scriptable заявки пользователи могут настроить его, связать его в автоматизированные потоки операций, и обычно делать его более полезным для себя способами, которые были слишком определенными для Вас для беспокойства, или что Вы даже не вообразили во-первых.

Существует несколько способов приблизиться к scriptability, но самый интересный и полезный должен представить уровень Вашего приложения модели. Этот срок прибывает из шаблона разработки контроллера представления модели (MVC): уровень модели содержит данные приложения и логику для работы на нем; уровень представления представляет те данные в видимой форме, скажите в окне; и уровень контроллера посредничает между ними, обновляя представление, когда модель изменяется и обновляя модель, поскольку пользователь управляет представлением. Для полного описания см. Шаблон разработки Контроллера представления Модели.

Представление модели, а не представления имеет два главных преимущества. Во-первых, модель обычно более стабильна, чем представление. Поскольку Вы производите новые версии своего приложения, кнопки могут переместиться, и команды могут измениться, но что фактически делает Ваше приложение является относительно постоянным. Если сценарии с точки зрения модели, то существующие сценарии и знание сценаристов остаются допустимыми. Во-вторых, модель более полезна, потому что она имеет отношение к фактической задаче, а не как сделать это. Например, если Вы хотите изменить имя файла в Средстве поиска, можно сказать, чтобы определить имя того файла, вместо того, чтобы описать ориентированные на представление шаги: выберите файл, щелкните по заглавной роли и введите некоторые символы.

Назад к началу.

Что такое AppleScript?

AppleScript является языком сценариев, создаваемым Apple Computer, и является основным языком для управления scriptable приложениями Macintosh. Это имеет подобный английскому языку синтаксис, строго объектно-ориентировано, и имеет несколько функций, делающих его уникально подходящим к работе с большим количеством объектов. Для полного изложения посмотрите Руководство по Языку AppleScript.

AppleScript обращается к проблеме того, чтобы быть специфичным для задачи необычным способом. Основной язык делает очень мало и не имеет никаких специфичных для задачи функций вообще. То, что это действительно делает, служат основой, в которую можно включить любое число специфичных для задачи функций, а именно, приложения. В зависимости от которого объекта Вы обращаетесь к, изменения словаря. Например, когда говорящий со Средством поиска, можно говорить о дисках, папках и файлах; когда говорящий с Почтой, можно говорить о сообщениях и почтовых ящиках; и т.д. Другими словами, приложения ответственны за обеспечение специфичных для задачи функций для задач, о которых они знают; AppleScript обеспечивает основную инфраструктуру и связующее звено для передачи информации от одного приложения до другого.

Назад к началу.

Основы

Интерфейс сценариев Вашего приложения распространен к остальной части мира, и система и человеческие пользователи, Вашим словарем. Это перечисляет все объекты и управляет, чтобы Ваше приложение поняло, вместе с тем, как они связаны и простые объяснения того, что они имеют в виду. AppleScript читает его, чтобы определить, как скомпилировать сценарии, и это - основная ссылка для сценаристов, хотящих знать то, что может сделать Ваше приложение. (Это не означает, что это должна быть единственная ссылка, которую Вы обеспечиваете. Это не было должно; идеально, Вы также обеспечите документацию и демонстрационные сценарии. Словарь требуется, все же.)

В этом разделе описываются некоторые общие руководящие принципы для создания Вашего словаря. Более поздние разделы содержат определенное руководство по определенным темам, таким как объекты или команды.

Мнение варьируется на том, необходимо ли записать целый словарь сначала и затем реализовать его, или запись и реализация многократно поразрядно. У обоих есть их преимущества – прежний упрощает быть непротиворечивым, последний упрощает поставлять в любое время – выбирают, какой бы ни работает на Вас.

Словари в настоящее время прибывают в три различных формата:

• aete: Исходный формат словаря. Это сохранено как ресурс Менеджера ресурсов типа aete, отсюда имя. Посмотрите Создание Ресурса Расширения Терминологии События Apple для дальнейшей документации.

• комплект сценария: собственный формат Какао. Комплект сценария является парой plist файлов, одно определение комплекта (.scriptSuite) и одна терминология комплекта (.scriptTerminology). Приложение содержит один или несколько комплектов сценария. В дополнение к условиям AppleScript комплект сценария также содержит информацию о том, как условия соединяются с классами реализации и методами, и говорит встроенную поддержку сценариев Какао, что сделать. Посмотрите, что Указание Приложения Пишет сценарий Поддержки дальнейшей документации.

• sdef: Короткий для сценариев определения, основанного на XML формата словаря. sdef является рекомендуемым форматом для записи словаря, так как это - надмножество других двух форматов и имеет явную поддержку без вести пропавших функций или не хорошо поддерживаемое в других, таких как синонимы. В то время как Вы не можете в настоящее время использовать sdef непосредственно, можно превратить его в любой из других двух форматов с помощью sdp инструмент. Посмотрите sdef (5) и sdp(1) страницы справочника для дальнейшей документации.

Для наблюдения словаря как, пользователь был бы, открыть его в Редакторе сценариев: запустите Редактор сценариев, выберите Open Dictionary из меню File и выберите Ваше приложение. Если Вы плохо знакомы со сценариями, исследуете некоторые другие словари. Средство поиска является хорошим примером: это следует инструкциям обоснованно хорошо и достаточно сложно, чтобы быть интересным, но достаточно простым быть понятным.

Рисунок 1: Часть словаря Средства поиска.

Перед началом

Думайте о scriptability ранее, а не позже.

Размышление о том, как подать Вашу заявку, scriptable рано в процессе проектирования, сэкономит Вам продолжительное время и муки. Во-первых, всегда проще реализовать опцию, планирующуюся с начала, чем соединить болтом его на в конце. Во-вторых, и что еще более важно, scriptability вынуждает Вас думать о Вашей модели. Если Вы знаете, каковы Ваши концептуальные объекты модели, можно создать объекты реализации то соответствие. Это не только делает scriptability проще, это - просто хорошая практика проекта.

Знайте свою модель.

Scriptability означает быть специфичным для задачи, и быть специфичным для задачи означает показывать вещи, которые делает Ваше приложение: т.е. Ваша модель. Поэтому важно, что у Вас есть твердое схватывание Вашей прикладной модели. Каковы объекты и команды, определяющие то, что Ваше приложение делает, и как они касаются друг друга? Например, Почта имеет почтовые ящики, почтовые ящики содержат сообщения, сообщения имеют адресатов и текст и могут быть отправлены или переданы и т.д. Заметьте, что это ничего не говорит о кнопках, командах меню или диалоговых окнах. Помните: модель, не просматривают.

Если Вы не можете выяснить то, что Ваша модель, или думайте, что Вы не имеете один, Вы, вероятно, или смотрите на нее неправильный путь или Ваша работа потребностей проектирования приложений. Говор с Вашими пользователями может быть полезным здесь – спрашивают их, что они делают и прислушиваются к общим объектам и командам.

Знайте своих пользователей.

Быть специфичным для задачи означает быть специфичным для задачи пользователем, не специфичный для задачи программист. Думайте о своем приложении с точки зрения вещей, которые пользователи делают с ним, не с точки зрения того, как Вы, конструктор, заставляете вещи произойти негласно. Для любого объекта или команды в Вашем словаре, для обычного пользователя Вашего приложения должно быть сразу очевидно, каково это. Если у Вас есть очень большое и сложное приложение, знание, что Ваши пользователи также услужливы в приоритезации, что сделать scriptable сначала. Вы не обязаны сделать все это сразу.

Знайте AppleScript.

Вы не должны изучать AppleScript в каждой подробности, но необходимо разработать чувство для синтаксиса команды типового приложения, и для того, что AppleScript сделает для Вас (и Вы поэтому не должны делать себя). Руководство по Языку AppleScript является официальной документацией Apple для AppleScript, но существует много сторонних книг, доступных также. Игрение с scriptable приложением, следующим инструкциям, таким как Средство поиска, является также хорошим способом учиться.

Используйте среду разработки приложения.

Значительная часть реализации scriptability должным образом включает реализующее стандартное поведение. Используя платформу устранит большую часть тяжелой работы и сократит количество ошибок (или по крайней мере гарантирует, чтобы у Вас были те же ошибки как все остальные использующие платформу). Какао Apple и PowerPlant Метрауэркса оба имеют хорошую поддержку scriptability.

Назад к началу.

Разработка Вашего словаря

Останьтесь на задаче.

Да, мы сказали это прежде, но это важно. Хороший scriptability фокусируется на задачах, которые значимы для пользователя. Если Вы говорите о кодах ошибки, битовых полях или других вещах, которые обычно не видит пользователь, то Вы смещаетесь вне задачи. Также помните, что задачи основываются на модели – т.е., что – не представление, которое является как. Если Вы говорите о кнопках и меню (и Вы не работаете над создающим интерфейс приложением), то Вы пытаетесь написать сценарий представления. Некоторые сценарии представления важны – видят Сценарии Представления – но это не фокус. Если Вы испытываете затруднения, думающие о задачах, помните эти две директивы вместо этого: говорите с пользователем, не программистом; и сценарий модель, не представление.

Если бы Вы испытываете затруднения, выражающие Вашу модель в способе, которым пользователь считал бы нормальным, это может быть знак что Ваша фиксация потребностей модели. (Это может также быть знак, что Вы нуждаетесь в перерыве, так попытка это, также.) Это иногда происходит: просмотр Вашей модели от различного угла может показать проблемы, которые не были очевидны прежде. Возможно, одна сложная работа должна быть разделена, или два объединенных, или возможно Вы не понимали домен задачи, а также Вы думали, что сделали. Разрешение и фиксирует его и фиксирует его в Вашем графическом интерфейсе также, если Вы можете – Вы иметь лучшее приложение для него.

Будьте объектно-ориентированы.

Быть объектно-ориентированным означает, что Ваши сценарии главным образом организованы вокруг объектов, не команд. Объекты могут реагировать на команды – документы могут быть распечатаны, сообщения могут быть отправлены, и т.д. – но фокус находится на объектах, не командах. Это обладает несколькими преимуществами:

Во-первых, это соответствует, как работает остальная часть AppleScript, и в некоторой степени Macintosh в целом. Это является поэтому более непротиворечивым и имеет больше смысла пользователям.

Во-вторых, это позволяет Вам использовать различные функции AppleScript, как tell блоки и whose пункты, таким образом, пользователи могут создать более краткие и мощные сценарии.

В-третьих, это позволяет Вам создать меньший, более понятный словарь, потому что можно применить мультипликативный эффект: n времена команд m доходы объектов n×m действия, но использование только n+m условия. Рассмотрите заявление, определяющее a widget объект с восемью свойствами. Для создания методов get и методов set для всех свойств с помощью только команды нам были бы нужны 16 команд с мучительно повторными именами: GetWidgetName, SetWidgetName, GetWidgetColor, и т.д. Быть объектно-ориентированным, однако, позволяет нам определить то же питание, использующее только 11 терминов: widget, get, set, и один для каждого свойства, с добавленным бонусом это get и set может быть снова использован.

Будьте точны.

Удостоверьтесь, что Вы фактически поддерживаете все, что Вы утверждаете, что в Вашем словаре. Будьте консервативны в своем словаре, если Вы должны; sdef обеспечивает способ скрыть условия, если Вы чувствуете, что они еще не готовы к прайм-тайму. (Так делает более старое aete формат, но намного более трудно использовать.)

На подобной точке удостоверьтесь, что типы, которые Ваш словарь определяет для свойств и параметров, точны. Примите во внимание, что точный отсылает к сценаристу (т.е. пользователь) перспективу, не конструктор. Например, нет никакого файла типа URL в AppleScript, но существует тип файла, поэтому даже при том, что Ваше приложение выбирает параметр как typeFileURL, определите его в своем словаре как file.

Не заново изобретайте колесо.

Чем меньше Вы изобретаете, тем более непротиворечивый Вы будете, и меньше Ваших пользователей должно будет учиться.

• Используйте в своих интересах наследование – если два или больше класса имеют общие аспекты, используйте наследование для создания общего базового класса для них так словарь не повторяет себя.

• Извлеките уроки из системы – AppleScript определяет много общих объектов, свойств и команд.

• Извлеките уроки из рынка – если другое приложение уже делает что-то, что Вы делаете, ищете общую терминологию.

Заключение к этому - то, что Вы не должны будете, вероятно, определять многие свои собственные команды. Стандартные команды заботятся об основных прикладных функциях и объектном манипулировании (open, quit, make, delete, и т.д. – посмотрите Команды для полного списка.), Например, Эскиз, демонстрационный графический редактор, не определяет ни одной из своих собственных команд – все, что Эскиз делает может быть выражен с точки зрения стандартных команд, главным образом путем получения и установки свойств объектов.

Нормально делать меньше, чем Ваш GUI.

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

Кроме того, это может не быть практично для создания всего в приложении scriptable одновременно: у Вас нет времени, Вы ожидаете, что функция изменится в следующем выпуске, безотносительно. Обеспечьте то, что Вы можете, сделать его полезным, и делаете остальных позже.

Нормально делать больше, чем Ваш GUI.

Scriptability является отличным способом представить функции в Вашем приложении, не имея необходимость реализовывать графический интерфейс для них. Иногда эти функции неявны в том, как работает AppleScript: например, Средство поиска не имеет никакой команды для удаления файлов, удовлетворяющих условию, но delete команда, объединенная со спецификатором объекта фильтра, выполнит просто это, как в delete every file whose name ends with ".jpg". Можно также представить аспекты модели через сценарии, но не через графический интерфейс, ли, потому что у Вас нет времени, не знайте, как, или просто не хотят загромождать GUI. Например, Адресная книга представила псевдоним и префиксные свойства для людей через AppleScript один выпуск прежде, чем добавить любой графический интерфейс для них.

Получите обратную связь.

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

Назад к началу.

Когда Вы думаете, что сделаны

Тест, тест, тест.

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

Получите больше обратной связи.

Внутренняя разработка и тестирование - все хорошо и хороший, но ничто не заменяет реальное использование. Позвольте реальным пользователям попробовать Ваше scriptable приложение. При обнаружении ошибки в scriptability после поставки можно все еще измениться, он, не повреждая существующие сценарии путем использования синонимов – видит sdef страницу справочника для подробных данных.

Назад к началу.

Стиль

В этом разделе описываются инструкции по стилю для Вашего словаря: организация, как назвать вещи, комментирует стиль и т.д.

Общие указания.

Используйте комплекты в качестве надлежащих.

Словари повреждаются в комплекты, которые являются кластерами связанных классов и команд. Они просто для преимущества читателя и не оказывают влияния на Ваше приложение или AppleScript. Нет никакого технического предела, или верхнего или ниже, на числе элементов в комплекте, но десять - пятнадцать считается удобным размером. Однако не вызывайте искусственные различия только, чтобы разбить большой комплект или объединить маленькие – окончательная точка должна помочь пользователю найти вещи.

Поместите определенные с помощью системы комплекты сначала, сопровождаемый Вашим собственным. Сортируйте их в порядке общности или частоты использования, или, приведя это к сбою, в алфавитном порядке.

В комплекте, и для свойств в классе, элементов порядка некоторым разумным способом. Для достаточно небольшой группы можно сортировать важностью или частотой использования, но это может быть трудно судить. Алфавитное упорядочивание всегда является хорошей нейтрализацией.

В команде упорядочьте параметры в пути, который целесообразен в предложении. Если это невозможно, используйте алфавитный порядок.

Будьте точны с типами.

При указании типа свойства или параметра, используйте наиболее определенный тип, который и точен и значим для пользователя. Часто, это - простой выбор определенного с помощью отдельного приложения класса или примитивного типа данных, но иногда это более интересно:

• Если существует несколько возможных типов, что все убывание от общего базового класса и все потомки базового класса законны, используют базовый класс.

• Если тип является списком некоторого другого типа, скажите так. (См. sdef's type="list of ..." или aete listOfItems бит.)

• Не утверждайте, что приняли все типы, если Вы действительно не имеете в виду его. (См. sdef's any введите, или aete typeWildCard.)

• Если Вы поддерживаете два или больше несвязанных типа – т.е. не связанный наследованием, как в первом случае – говорят так. (См. sdef's type="T1 | T2 | ...". Выполнение в этом aete является возможным, но неловким.)

Вещами, относящимися к объектам, должны быть объекты.

Если свойство или параметр относятся к объекту, его тип должен быть фактическим объектом, никогда данные, показывающие объект. Рассмотрите эту команду от многих веб-браузеров, повреждающую эту инструкцию (и несколько других):

Корректный способ сделать это должно определить a close команда, воздействующая на window объекты, которые могут тогда быть указаны по имени, ID или несколько других путей. Это позволяет больше гибкости и более просто определить.

Несколько слов о файлах

Файлы в AppleScript считаются объектами. Поэтому свойства и параметры, указывающие на файлы, должны также быть file объекты. Не используйте строки пути к файлу с этой целью. Точно так же не имейте строк пути к файлу использования нигде – используют a file объект, и позволил сценариям использовать path свойство файлов, если они действительно должны. (Сценарии какао поняли это превратно, когда они были сначала реализованы. Это исправляется; Вы не должны рассматривать его как давание разрешения.) Используют sdef's file введите; это сделает корректную вещь (или по крайней мере самую корректную возможную вещь).

Назад к началу.

Выбор элементов языка

Свойства по сравнению с элементами

Объекты могут содержать другие объекты; их или называют свойствами (inbox of application "Mail") или индексированные элементы (mailbox 3 of application "Mail"). Общее правило состоит в том, что, если существует точно один объект, используйте свойство; если может быть какое-либо число, используйте элемент. Для полных подробных данных посмотрите Объекты.

Свойства по сравнению с командами

Установка Sometimes свойство может вызвать непосредственное изменение на экране. В решении, использовать ли свойство в этой ситуации, полезное правило: Когда действие будет инициироваться, используйте команду; когда атрибут изменяется (даже если он приводит к непосредственным видимым результатам), используйте свойство. Другой способ смотреть на это состоит в том, если видимое изменение непосредственно, используйте свойство, но если действие имеет продолжительность, используйте команду.

Например, следующая команда вызывает непосредственное изменение на экране:

set the font of the third paragraph to "Courier"

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

set playing to true 
set [the] status to playing

playing значение перечислителя во второй команде хорошо для получения информации состояния, но свойство состояния должно быть только для чтения. Вместо того, чтобы создать свойство для управления действием используйте команду. Команды, такие как игра или начинают играть, лучше подходят для действий, как показано здесь:

play the movie "Wowie Zowie" 
start playing the movie "Wowie Zowie"

Обратите внимание на то, что команды play и start playing, нет play movie и start playing movie. В надлежащей модели сценариев, movie был бы класс объекта.

Перечисления

Перечисление является рядом констант (перечислители), представляющие фиксированный набор выбора. Используйте перечисление в качестве типа параметра или свойства каждый раз, когда существует выбор, который будет сделан из определенного списка возможностей. Это помогает пользователю видеть, что существует выбор и сообщает им точно, каков выбор.

Таблица 1: перечисления

Назад к началу.

Именование правил

Используйте пользовательские термины, не условия реализации.

Помните, что Вы говорите с пользователем и должны поэтому использовать термины, которые они сочтут знакомым. Идеально, термины, использованные в Вашем графическом интерфейсе, сценариях и документации, должны все соответствовать.

Используйте тест.

AppleScript позволяет Вам добавлять или удалять слово the почти нигде в сценарии, не изменяя значение сценария. Много писателей сценария предшествуют объекту и именам свойства со словом the сделать их сценарии проще читать. Запись Ваших сценариев тестирования таким образом помогает Вам определить градус, до которого Ваши имена свойства упрощают формирующиеся естественные предложения.

set the service to "America Online"
if the priority is high then ...

Не использовать the как часть срока. Сценаристы приучены к the быть дополнительным, но использование его в сроке делает, это потребовало.

Используйте нижний регистр.

Используйте все строчные буквы для своих условий, за исключением требуемого для имен собственных, торговых названий и акронимов.

Таблица 2: капитализация

Используйте многократные слова, не InterCaps или подчеркивания.

Если срок состоит больше чем из одного слова, разделите слова пробелами. Не присоединяйтесь к словам вместе с прописными буквами или подчеркиваниями. Снова, торговые названия являются исключением к этому.

Таблица 3: примеры.

Условия должны соблюсти правила идентификатора AppleScript.

Каждое слово в сроке должно быть допустимым идентификатором AppleScript. Это означает, что они должны начать с буквы или подчеркивания, и сопровождаться любым числом букв, числами или подчеркиваниями, то же как подобные языкам C. Пунктуация не позволяется; подчеркивания не рекомендуются, как упомянуто выше.

Не создавайте команды, которые похожи на объекты или объекты, которые похожи на команды.

Создание условий, которые похожи на другие части речи, смутит сценаристов и приведет их пробовать вещи, которые не будут работать. Рассмотрите команду Standard Additions set the clipboard to: видя его в сценарии, Вы могли бы думать, что это - a set команда, воздействующая на a clipboard свойство, но это действительно не, таким образом, предположительно, эквивалентно copy x to the clipboard не работал бы.

Не запускайте имена свойства с обязательных глаголов.

Когда свойство появляется посреди предложения, стартовые имена свойства с глаголами приводят к беспорядку. Например, именование свойства disable call waiting приводит к командам, не читающим гладко:

set disable call waiting to true 
if disable call waiting then ...

Кроме того, имя отключают ожидание вызова, похож на команду. Пользователь мог бы испытать желание сказать

disable call waiting

Это будет компилировать и работать, но ничего не отключает – это просто возвращает текущую стоимость свойства. Можно предотвратить такой беспорядок при помощи причастия вместо этого. Это несколько более ясно:

set call waiting enabled to false 
if not call waiting enabled ...

Еще лучше должен был бы назвать свойство call waiting и используйте перечисление в качестве его типа значения. Выбор enabled и disabled позвольте грамматически корректные предложения:

set call waiting to enabled 
if call waiting is disabled ...

Избегите начинать условия с ключевых слов языка.

Используя ключевое слово языка, поскольку первое слово в сроке может лишить возможности использовать то ключевое слово в определенных контекстах. Например, рассмотрите заявление, определяющее a mailbox содержащий класс message объекты. Добавление свойства приложения называют in mailbox препятствовал бы тому, чтобы сценаристы использовали ключевое слово in как синоним для of в некоторых случаях: messages in mailbox 1 был бы проанализирован как messages in mailbox 1, который недопустим вместо намеченного messages in mailbox 1.

Возможно успешно начаться, условия с ключевыми словами – рассматривают команду Standard Additions set the clipboard to – но это не рекомендуется. Условия могут использовать ключевые слова языка в середине или в конце условий, но видеть некоторые следующие инструкции.

Таблица 4: Зарезервированные слова в AppleScript 1

Избегайте использования 'находится' в булево свойстве и названиях параметра.

Это - конкретный случай предыдущего правила: is зарезервированное слово, означающее, равно. Например, вместо is minimized, is encrypted, или is busy, использовать minimized, encrypted, и busy.

Кроме того, синтаксический анализатор AppleScript надевает несколько специальных приемов на булево свойства и параметры, заставляющие их читать лучше без.

AppleScript изменится true и false в булевых параметрах к with и without. Например, если пишет сценарист

send message "Fred" queuing true

это компилирует в

send message "Fred" with queuing

Кроме того, тесты булево свойств могут быть записаны особенно: вместо высказывания property из object истина (или ложь), можно сказать object (или не), property. Например, следующие две строки эквивалентны:

if miniaturized of window 1 is true then ... 
if window 1 is miniaturized then ...

Если назвали свойство is miniaturized, вторая строка должна была бы быть записана if window 1 is is miniaturized, который является неловким. Заметьте, что эти специальные формы читают лучше всего, если имя свойства является просто прилагательным, не группой прилагательного такой как has x или wants x.

Избегайте использования на имя.

Of зарезервированное слово, используемое между частями объектного спецификатора. AppleScript позволит Вам сойти с рук это, но может очень сбить с толку читать, потому что это заставляет срок быть похожим на свойство объекта, который это не.

Избегайте использования 'конца' как первого слова в команде.

Несколько AppleScript создают использование end закончить блок: end if, end repeat, и т.д. В этих случаях AppleScript заполнит слово после end автоматически. Пользователи могут испытать желание попробовать ту же вещь Вашей командой, и это не будет работать.

Таблица 5: Примеры условий.

Назад к началу.

Стиль комментария

Любой срок словаря может иметь связанный комментарий (sdef's и терминология комплекта description атрибуты, или aeteполя комментария). Используйте их, чтобы помочь разъяснить, как должен использоваться Ваш словарь. Так как Ваш словарь часто является начальным окном, через которое пользователь надеется выяснять, что сделать, дескриптивные комментарии могут сделать задачу пользователя намного проще. Помните, что Ваши пользователи являются не обязательно программистами, поэтому избегите условий реализации в своих комментариях.

• Для булевых параметров и свойств, если существует два возможных состояния, включают описание истинных и ложных условий, таких как истина, если сценарий изменит исходные изображения, ложь, если изображения будут оставлены в покое.

• Если возможные состояния идут и прочь, Вы должны только включать истинное условие (Если это правда, то экранируйте обновление, включен), или задайте вопрос начиная с, или делает (Окно масштабируется?).

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

• Не используйте поле комментария для объяснения ряда возможных числовых значений, когда перечисление (с дескриптивными перечислителями) будет лучше. Вместо 0=read, 1=unread, … используют чтение | непрочитанный | …

• При разрешении больше чем одного типа (см. sdef's type="T1 | T2 | ..."), включайте описание выбора для перечисленных типов: окно соединения (или ссылка или имя могут использоваться).

• Если параметр или свойство имеют значение по умолчанию (используемый, когда пользователь не включает дополнительный параметр или установить свойство), упомяните его. Это применяется к значениям любого типа: замена да | не | спрашивает - Замена файл, если это существует? (значения по умолчанию для выяснения).

Назад к началу.

Объекты

Поскольку AppleScript таким образом объектно-централен, определяя разумную иерархию объектов, и иерархия классов и создание его вести себя всеми стандартными способами являются, возможно, самой важной частью создания хорошего интерфейса сценариев для Вашего приложения. Перефразировать Фреда Брукса немного: Покажите мне свой код и скройте свои объекты, и я буду продолжать быть мистифицированным. Покажите мне свои объекты, и мне обычно не будет нужен Ваш код; это будет очевидно.

Разработка Ваших объектов

Как всегда, основное правило быть определенной задачей. Покажите объекты, имеющие прямое влияние на вещи, которые пользователь сделает с Вашим приложением. Представьте модель, не интерфейс. Не показывайте подробные данные реализации – пользователи не будут заботиться, или хуже, это смутит их.

Существует две различных иерархии для рассмотрения: иерархия наследования – что ведет себя как то, что – и иерархия вместимости – кому принадлежит что. Заставьте свои иерархии соответствовать то, что ожидал бы пользователь.

Наследование

AppleScript поддерживает единичное наследование, таким образом, можно определить класс, чтобы быть точно так же, как другой класс, но с дополнительными свойствами или элементами. Подкласс не должен определять новые части; иногда просто быть различным классом достаточно. Почта recipient классы делают это.

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

Назад к началу.

Включение

AppleScript определяет два вида отношений включения: элементы и свойства. В условиях моделирования связи сущностей элемент к - многие отношение, и свойство является или атрибутом или к - одно отношение. (Моделирование связи сущностей различает примитивные данные и другие объекты; AppleScript не делает.) В то время как может быть любое число элементов, свойство является единственным значением. Особые случаи, такие как zero-one или любое число в диапазоне могут быть эмулированы с помощью свойств или элементов с дополнительным поведением, как показано здесь:

Таблица 6: терминология Включения.

В целом предпочтите элемент свойству, значение которого является списком объектов – это является более непротиворечивым и является проще реализовать. В частности не делайте чего-то вроде этого:

class widget (pl. widgets)...

class box:

     property widgets: list of widget

Это является особенно злым, потому что это делает widget будьте похожи на элемент box когда это действительно не. Например, widgets of box 1 работы, и похожи на каждый спецификатор, но, предположительно, эквивалентный every widget of box 1 перестанет работать, потому что это был действительно спецификатор свойства.

При реализации такого свойства (см. стандарт selection свойство для примера), удостоверьтесь, что оно работает точно нормальным контейнером в объектных спецификаторах – подклассы элемента, фильтры, и т.д. должны все работать.

Назад к началу.

Объектные спецификаторы

Все объекты в приложении, кроме корня application возразите, содержатся некоторым другим объектом. Для выбора определенного объекта или набора объектов сценарий использует объектный спецификатор или спецификатор для краткости который является выражением формы object-expression of container. Container самостоятельно объектный спецификатор, таким образом, приложение рекурсивно прокладывает себе путь цепочка включения, пока это не достигает (часто подразумеваемый) корень application объект, содержащий все. Например:

Подчеркнутые части показывают каждый компонент. Заметьте, что каждый компонент использует различную ключевую форму. Полный набор ключевых форм перечислен в таблице ниже. Формы ключа Most подразумевают существование определенного свойства для того объекта: если объект имеет то свойство, то это должно поддерживать ту ключевую форму, и наоборот.

Таблица 7: объектные спецификаторы

Кроме того, допустимые ключевые формы для контейнера определяются природой контейнера и его элементов. Это также определяет, какие расположения, если таковые имеются, значимы для make и move команды. Существуют, широко, три типа контейнеров:

В упорядоченном контейнере пользователь определяет точно, как располагаются элементы. Любой элемент может быть помещен прежде (или после) любое другое использование элемента make или move, и это останется там. Абзацы текстового документа упорядочиваются, как элементы в списке AppleScript.

В неупорядоченном контейнере сами данные определяют порядок элементов – например, алфавитный порядок – или просто нет никакого определенного порядка. В то время как можно попросить nэлемент th, выполните итерации через всех них или говорите об элементе прежде или после другого, прося делать элемент в, или перемещаться это в определенную позицию бессмысленно – все, что можно сделать, просят помещать его в контейнер. Людям в Адресной книге, файлам в Средстве поиска и элементам в записи AppleScript все не упорядочивают.

В бесчисленном контейнере не знает приложение, сколько там элементы. Все индексные формы бессмысленны, как идея every. Для получения элемента необходимо знать что-то еще об этом: его имя, его ID, некоторое свойство, или подобный. Веб-серверы в Интернете бесчисленны.

Таблица 8: объектные типы спецификатора

Ключевые формы

Этот раздел предоставляет подробную информацию поведения для каждой из ключевых форм. Это не дает подробные данные использования или синтаксис; для этого см. Главу 5 Руководства по Языку AppleScript.

Произвольный

При поддержке этой ключевой формы она должна возвратить по-настоящему случайный объект, не всегда того же самого. Эта ключевая форма полезна каждый раз, когда для сценария нужно случайное поведение. Например, сценарий мог выбрать случайную подпись в Почте путем высказывания some signature, вместо более сложного signature (random number from 1 to (count signatures)).

Каждый

every item эквивалентно items 1 through -1, за исключением того, что every при отсутствии элементов вместо ошибки, возвращает пустой список. Дополнительную информацию см. в Диапазоне.

Фильтр

По историческим причинам Фильтр считают его собственной ключевой формой, хотя это было бы больше с точностью до, думают о нем как о модификаторе к основанным на индексе ключевым формам (индекс, произвольный, средний, диапазон и каждый). В то время как ключевая форма фильтра чаще всего используется с тестом на свойстве объекта (такой как files whose name contains "Smith"), тесты на элементе или самом объекте также допустимы. Например:

paragraphs where it starts with "The"
albums where it contains photo "White Rabbit" 
documents whose first paragraph contains the word "Metacortex"

В теории любое булево выражение должно быть допустимым, но AppleScript в настоящее время не может иметь дело с вызовами функции в выражении фильтра.

Если объекту на рассмотрении не указывали атрибут в фильтре, это не ошибка – полагают, что значение missing value и ответьте соответственно.

ID

Возвращает отдельный объект чей id свойство соответствует указанное значение. Данные ID не должны соблюдать текущие соображения AppleScript, такой как considering case. Обработайте IDs как всегда нечувствительный к регистру, или как всегда чувствительный к регистру, если случай релевантен (т.е. если "ijkl" и "IJKL" и допустимы и отличаются).

Индекс

Элемент indicies должен соответствовать модель пользователя первого для длительности или упорядочивание грудь-спина. (Фактически, first и front синонимы в AppleScript, как last и back.) Это означает это window 1 должно всегда быть переднее окно, table 1 должна быть первая таблица в документе, и т.д. Отрицательные indicies идут назад от конца, таким образом, item -1 и last item имейте в виду ту же вещь, item -2 предпоследний элемент, и т.д.

Если элементы не упорядочиваются, как определено выше, то идеально индекс должен соответствовать, как элементы в настоящее время выводятся на экран. При сбое этого выберите непротиворечивый порядок – говорят, алфавитный – и использование это.

Именованный

Возвращает отдельный объект чей name свойство соответствует указанную строку. Сопоставление строк должно соблюдать текущие соображения AppleScript, такой как considering case или ignoring diacriticals. Даже если Вы не используете полный Unicode внутренне, данные имени могут прийти к Вашему приложению как плоскость или текст Unicode, так быть подготовлены обработать также.

Диапазон

Диапазоны могут быть указаны или как два indicies или как два объекта конечной точки, включенные в диапазон. Если или конечная точка не существует, или если они не находятся оба в том же контейнере, возвратите ошибку. Инструкции для значения indicies применяются что касается индексной ключевой формы выше.

Порядок конечных точек не имеет значения – всегда возвращают объекты в порядке, самом низком индексе к самому высокому. Например, words 8 through 1 должен возвратить ту же вещь как words 1 through 8.

Текст представляет особый случай: из-за того, как работает его включение, возможно указать две конечных точки, где каждый в другом. (Обычно, это было бы недопустимым диапазоном, потому что два объекта будут иметь различные контейнеры.) Для разрешения этого найдите начало обеих конечных точек, запуститесь с одно самое близкое к началу текста, и затем пойдите до конца другого объекта конечной точки. Например:

set t to "Through three cheese trees three free fleas flew"

words from paragraph 1 to word 3 of t
--> {"Through", "three", "cheese"}

characters from character 10 to word 2 of t
--> {"h", "r", "e", "e"}

Даже если диапазон содержит только один объект (или, в случае каждого, никаких объектов), спецификаторы диапазона всегда возвращают список. Если ссылка на диапазон используется в качестве контейнера для другого свойства или объекта, результат состоит в том что свойство или объект каждого элемента в диапазоне. Например:

name of files 2 thru 3 of home
--> {"Memory report", "BBEdit update.dmg"}

Список значений возвратился, должен всегда быть параллельным списку, который был бы возвращен для диапазона. Т.е. это должно быть в том же порядке и иметь то же число значений. Например:

every duck --> {mallard "Daffy", pintail "Marvin", decoy duck "Q-36"}

name of every duck
--> {"Daffy", "Marvin", "Q-36"}

Даже если некоторые объекты не имеют указанного свойства или элемента, это применяется. Для таких объектов возвратиться missing value. Продолжение примера, рассмотрите, футы являются перепончатым свойством, учитывая что ловушки не имеют футов:

feet are webbed of every duck
--> {true, true, missing value}

Если указанный элемент является другим диапазоном, то результатом является список списков. Например:

every duck of every flock
--> {{mallard "Ned", mallard "Ted"}, {pintail "Ann", pintail "Dan"}}

Относительный

Относительные спецификаторы имеют форму class (before | after) specifier, где specifier может быть любой другой спецификатор, включая другой относительный спецификатор. Поэтому word after word after word 1 совершенно допустимый способ описать третье слово. Это может казаться странным, но релевантно при работе с текстовыми выборами: если выбор является точкой вставки, скажем, insertion point after word 12 слово после той точки было бы word after insertion point after word 12.

Назад к началу.

Элементы и наследование

Контейнер не должен определять отличное отношение элемента для каждого класса, который он содержит – он может подразумевать их наследованием. Если объект содержит объекты некоторого класса, спецификатор может указать любой подкласс, и запрос будет ограничен объектами того класса. Например, рассмотрите фиктивное заявление DuckTracker:

Даже при том, что это только явно указывает duck как элемент, сценарий мог попросить every mallard и получите список всех диких уток.

Назад к началу.

Возврат объектных спецификаторов

На объект в Вашем приложении можно обычно ссылаться одним из нескольких способов. Например, window 1, window "Lister", и window id 743 мог бы все относиться к тому же окну. Если необходимо возвратить объект, хотя – говорят, что сценарий просит получать первое окно, имя которого начинается с «L» – необходимо будет выбрать определенную ключевую форму. Форма, которую Вы выбираете, известна как канонический объектный спецификатор и должна быть самым надежным способом относиться к тому объекту. Т.е. это получает лучшую возможность обращения к тому же объекту позже, как изменяются вещи.

Общее правило для формы для использования:

• Если объект имеет id свойство, используйте это. (window id 743)

• Если объект имеет a name свойство, используйте это. (window "Lister")

• Иначе, используйте его индекс (window 1). Индекс должен всегда быть положительным.

Класс объектного спецификатора должен быть фактическим классом объекта. Продолжая пример DuckTracker сверху, это было бы чем-то как mallard id 8237, нет duck id 8237, даже при том, что оба обращаются к тому же объекту.

Назад к началу.

Необычные проблемы

Many-one и many-many отношения

В большинстве приложений все объектные отношения являются непосредственными или one-many, результат, являющийся, что все объекты содержатся точно одним другим объектом. Некоторые приложения, однако, имеют many-one или many-many отношения, таким образом, отдельный объект может появиться в нескольких различных контейнерах. iPhoto ведет себя как это: a photo объект может быть в любом числе albums. Нет ничего неправильно с этой моделью, но она действительно требует определенных корректировок.

Во-первых, необходимо поддерживать команды add и remove. Эти команды разработаны, чтобы только управлять включением, в противоположность созданию и уничтожению объектов как make и delete сделать. Различие важно потому что make и delete не имейте прямых значений для некоторых задач. Скажите, что Вы хотите добавить существующую фотографию к альбому в iPhoto. make не является действительно надлежащим, так как Вы ничего не делаете. Точно так же скажите, что Вы хотите удалить фотографию из альбома. delete неоднозначно: это просто удалит фотографию из того альбома, или это удалит фотографию полностью? Вы могли разрешить проблему без различных команд путем представления фото ссылочного объекта, за исключением того, что нет такой вещи в пользовательской модели и поэтому не нарушила бы пребывание инструкция на задаче.

Во-вторых, действительно ли это возможно для Ваших объектов (вызовите их фотографии, для продолжения аналогии iPhoto) не принадлежать какому-либо определенному контейнеру (альбом)? Например, в iPhoto, фотография может не быть ни в каком альбоме. Если это верно, тогда необходимо будет определять единственный основной контейнер, содержащий все фотографии; они могут быть добавлены к и удалены из альбомов оттуда. (использование iPhoto application для этого.) В противном случае тогда Вам не нужен основной контейнер, но удаление фотографии из ее последнего альбома должно удалить его.

Несимметричные спецификаторы

В целом, если объект получен определенным свойством, то свойство объекта должно соответствовать. Например, name of thing "Bob" должен всегда быть "Bob", id of thing id 427 должен всегда быть 427, и т.д.

В некоторых приложениях, однако, это может не иметь место. Как правило, причина состоит в том, что объект может иметь больше чем одно допустимое имя (или ID, и т.д.). Например, Средство поиска application file класс реагирует на ID или типа создателя старого стиля или модернизированного ID пакета: application file id "emal" и application file id "com.apple.mail" оба возвращают ту же вещь.

Совершенно приемлемо для многократных ключевых данных возвратить тот же объект. (Если это создает случаи неоднозначности, то посмотрите ниже.) Однако у Вас должен быть некоторый способ для пользователя обнаружить все различные данные, которыми может быть указан объект. Основное свойство (например, name) должен отразить канонические данные; добавьте другие свойства для остальных. Например, если расширение файла будет скрыто в Средстве поиска, то оно будет реагировать на любого видимое имя (без расширения) или дисковое имя (с расширением). Дисковое имя считают каноническим именем; видимое имя доступно через displayed name свойство.

Групповые ключевые формы

Как правило, имена и IDs уникальны, по крайней мере, в в контейнере, таким образом, существует только один объект folder "Bob" мог возможно возвратиться. Однако это не всегда имеет место – например, в некоторых приложениях, имена просто для справочника пользователя, и приложение не предпринимает попытки сохранить их уникальными.

Для таких приложений вызовите быть непротиворечивыми о правиле типов возврата: названный и индексированные ключевые формы обычно возвращают отдельный объект, таким образом, они должны все еще сделать так даже перед лицом неоднозначных объектов. Если один объект является лучшим соответствием, чем другой, возвратите тот; если нет никакого лучшего соответствия, возвратите первый. Однако гарантируйте, что пользователи могут выбрать все соответствующие объекты с помощью выражения фильтра некоторого вида, такой как every item whose name is ...

Назад к началу.

Стандартные классы

Существует несколько стандартных классов, которые должны определить приложения. Единственный, который должно определить приложение, application, корень иерархии вместимости. (Корень иерархии наследования, item, определяется самим AppleScript и не должен появляться в Вашем словаре.) Свойства, показанные здесь, являются просто начальными точками; реальное приложение должно будет определить больше, начиная с тех показанных здесь почти ничего не делают. Классы и свойства могут быть опущены, если они не относятся к приложению. Например, не все приложения имеют документы, или даже выбор. Точно так же свойства, отмеченные здесь как только для чтения, могли бы быть перезаписываемы (или наоборот) в некоторых приложениях.

application корень иерархии вместимости. Т.е. это содержит, прямо или косвенно, все объекты, принадлежащие приложению. window элементы являются только теми окнами приложения, содержащими другие scriptable объекты, такие как окна документа – модальные диалоговые окна, листы, и форматирование или палитры инструментов не должны быть включены. (Палитры могут быть включены как свойства, как бы то ни было.)

Документ приложения. name свойство является видимым пользователем именем, не дисковым именем. name и file обычно только для чтения; используйте save команда для изменения их.

Окно, которое может быть окном документа или палитрой, но не листом или модальным диалоговым окном. bounds дан как список четырех чисел: {вершина, оставленная, нижняя часть, право}, с источником, наверху оставленным дисплея и x, y значения, увеличивающиеся вправо и вниз, соответственно. (Другими словами, прямоугольник Quickdraw. Это отличается от AppleScript Studio, возвращающего границы как {оставленный, нижняя часть, право, вершина}, с источником в нижней левой части и x, y значения, увеличивающиеся вправо и.) visible относится к тому, видимо ли окно как с показать/скрыть командой, не, было ли окно перемещено для расположения главным образом вне экрана.

Корень иерархии наследования и окончательный наследователь всех классов. Посмотрите ниже для полных описаний class и properties свойства. С тех пор item определяется AppleScript, это не должно появляться в Вашем словаре. В частности не переопределяйте item с дополнительными свойствами или элементами – создают Ваш собственный класс с другим именем. Классы не должны явно определять это, они наследовались от item – если нет никакого другого родителя, item принят.

Назад к началу.

Стандартные свойства

класс

Класс объекта. Это должно всегда быть точным классом, никогда суперкласс, и всегда только для чтения. Вы не должны явно определять class в Вашем словаре, так как это определяется item, который является окончательным наследователем всех классов.

контейнер

Объекты в иерархии вместимости могут определить контейнерное свойство, указывающее на их вложенный объект. (Это свойство является чисто дополнительным, потому что часто трудно реализовать.) Точное имя зависит от возможных контейнерных классов: если существует точно один, назовите свойство тем же как класс. Например, сообщения в Почте всегда принадлежат почтовому ящику, и поэтому имеют a mailbox свойство. Если существует несколько возможностей, используют общий термин container. Например, файл в Средстве поиска может принадлежать или папке или диску. Не используйте термин parent, так как это относится к непосредственному наследователю объекта в иерархии наследования.

Контейнерное свойство только для чтения. Запись в контейнерное свойство для перемещения объектов не рекомендуется; используйте move команда вместо этого.

Объекты во много-к -x отношения могут не иметь единственного значимого контейнера. Такие объекты должны опустить это свойство, но, несомненно, должны будут поддерживать спецификаторы формы containers where it contains object.

содержание

Если содержание объекта может быть представлено как единственное значение, оно должно определить a contents свойство. Например, документы, одним словом, процессор определили бы a contents свойство, возвратившее весь текст как строку. contents обычно перезаписываемо.

все содержание

Рекурсивные контейнеры – т.е. объекты, имеющие их собственный класс как элементы – должны определить entire contents свойство, возвращающее плоский список, содержащий каждый порожденный элемент. entire contents самостоятельно всегда только для чтения, но элементы его могут быть перезаписываемы.

ID

Значение, однозначно определяющее объект. IDs никогда не локализуется и обычно находится не под управлением пользователя и поэтому только для чтения. Они должны, по крайней мере, быть уникальными в контейнере – в большинстве приложений, они уникальны в целом приложении – и должны остаться допустимыми для, по крайней мере, времени жизни порядка подачи заявки или объекта, какой бы ни заканчивается сначала.

Тип имеющий значение может быть чем-либо: общим выбором является целое число, UUID или идентификатор пакета. Тип имеющий значение для любого определенного класса должен всегда быть тем же.

имя

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

свойства

Все объекты должны иметь a properties свойство, возвращающее запись, содержащую все свойства объекта. Вы не должны явно определять properties в Вашем словаре, так как это определяется item, который является окончательным наследователем всех классов. Если какие-либо свойства перезаписываемы, то properties также и может принять запись, содержащую любое число свойств для того объекта. Например:

получите свойства абзаца 4 - шрифт Возвратов, размер, стиль, и т.д. установите свойства абзаца 4 к {шрифт: «Helvetica», size:14} - Наборы просто шрифт и размер.

properties свойство не должно включать каждое свойство объекта. Как правило, свойства, которые могут быть получены из других свойств, не включены, такой как reverse свойство списка.

Назад к началу.

Команды

Команды в AppleScript определяются независимо от любого определенного объекта; класс может тогда перечислить команды, на которые он отвечает. К Java и программистам Objective C, команды поэтому напоминают протоколы больше, чем функции членства. В настоящее время нет никакого прямого способа определить команду по-другому (скажите с различными параметрами) для определенного класса. Лучшее, которое можно сделать, должно или перечислить все возможные параметры и использовать комментарии для высказывания, какие параметры значимы, когда, или определить разделяют команды различными именами.

Разработка Ваших команд

Будьте подобны английскому языку.

Команды AppleScript обычно похожи на обязательные английские предложения:

Попытайтесь эмулировать этот стиль со своими собственными командами. Однако примите во внимание, что это - инструкция, таким образом, Ваш английский стиль не должен быть совершенным. Кроме того, Вы ни в коем случае не обязаны поддерживать все возможные английские предложения. Синонимы прекрасны, где они целесообразны, но не идут за борт.

Не изобретайте команды, если Вы не имеете к.

Попытайтесь использовать стандартные команды, где это целесообразно, и только создайте свои собственные команды, если существует ясная потребность. Например, Почта отправляют, действие не вписывается в стандартные команды никаким очевидным способом, таким образом, это получает свою собственную команду. С другой стороны, Средство поиска не определяет a rename команда, потому что это может просто установить значение объекта name свойство.

Исключительные возвращаемые значения спецификаторов, диапазоны и 'каждый' возврат списки.

В целом команды, возвращающие результат, должны возвратить ту же форму результата как прямой спецификатор параметра: исключительные спецификаторы возвращают пустые значения, диапазон и every спецификаторы возвращают списки. (Существуют исключения к этому; посмотрите count и exists.) Спецификатор диапазона, где одна или обе конечных точки не существуют, является ошибкой; every спецификатор, не указывающий объектов, не. Это правило также применяется к отфильтрованному диапазону и every спецификаторы. Например:

-- Singular specifiers like index return a value.
get name of person 1
--> "Fillmore"

-- Range and "every" specifiers return a list... 
get name of every person
--> {"Fillmore", "Poppleton"}

-- ...even if there is only one object... 
get name of every person whose name starts with "P" 
--> {"Poppleton"} 

-- ...or even no objects for "every"... 
get name of every person whose name starts with "Q" 
--> {} 

-- ...but both endpoints must exist for a range. 
get name of people 1 through 17 
--> Error: Can't get person 17.

Команды, нарушающие это правило – например, учитывая диапазон они иногда, возвращают значение, и иногда список – является раздражающим для использования, потому что они требуют, чтобы пользователь записал логику для обнаружения то, что произошло. Дополнительную информацию см. в Ключевых Формах.

Используйте цель.

Предмет самого внутреннего tell блок является целью. Используйте цель для завершения параметров, которые опускает сценарий. В некоторых случаях AppleScript сделает это для Вас: так как цель обычно соответствует прямому параметру, AppleScript автоматически передаст цель как прямой параметр, если команда потребует один, и сценарий не предоставляет его. В некоторых случаях, однако, цель целесообразна как предложный параметр. Рассмотреть add x to y: было бы разумно сказать tell y to add x вместо этого. Ваше приложение может обнаружить без вести пропавших to параметр и выбор цель из подчиненного параметра, дополнительный параметр, в котором AppleScript передает цель.

Используйте ошибочные возвращаемые параметры, не коды состояния.

Возвращаемое значение команды AppleScript должно всегда быть значением или объектным результатом команды, никогда код состояния или сообщение. Если нет никакого результата – т.е. команда только выполняет действие – ничего не возвращают.

Для сигнализации ошибки возвратите ненулевой код ошибки из обработчика событий или установите kOSAErrorNumber параметр в ответе. Используйте коды стандартной погрешности, где это необходимо, в частности ошибочный диапазон AppleEvent от-1700 до-1799 (описанный в Кодах Результата в Ссылке менеджера по корпоративным мероприятиям Apple). Использование дополнительных параметров ошибок такой как kOSAErrorOffendingObject (см. OSA.h для полного списка), настоятельно рекомендован – идея состоит в том, чтобы возвратить максимально определенную ошибку. Например, скажите, что сценарий передает список, где Ваша команда хотела число:

Таблица 9: Обработка ошибок.

Пользователя, отменяющего работу, считают ошибкой; использовать userCanceledErr (-128) когда это происходит.

Никакое взаимодействие не требуется.

Сценарии команд не должны требовать никакого взаимодействия с пользователем, так как часть точки сценариев должна создать полностью автоматизированные функции. Если информация была опущена от команды, такой как попытка к, приемлемо взаимодействовать с пользователем save never-saved файл, не указывая расположение, но должен всегда быть параметрами, доступными, таким образом, сценарий может работать без любого взаимодействия. Команды никогда не должны просить подтверждение. Например, empty trash команда сценария в Средстве поиска не просит подтверждение, даже при том, что команда меню делает.

Прежде, чем попытаться взаимодействовать с пользователем в ответ на команду сценариев, вызвать AEInteractWithUser. Если это возвращает ошибку, не взаимодействуйте – или обойдитесь без пользовательского интерфейса или сбоя. Это позволяет сценариям указать, хотят ли они позволить взаимодействие.

Управляйте числом параметров.

Иногда можно реализовать команду, содержащую много опций, для которых Вы могли бы испытать желание сделать отдельные булевы параметры. Когда число параметров является маленьким, выглядит хорошим быть в состоянии сказать с a, b, и c. Злоупотребление этим методом, однако, может привести к громоздким словарным статьям для этих событий с длинными списками параметров.

Существует два решения этого: или сделайте параметр или параметры, принимающие список перечислителей для опции или набора опций, или повреждающиеся, команда в разделяют команды более фокусируемой функциональностью, сокращая число вариантов для каждого.

Например, предположите, что пакет статистики создает единственную команду для выполнения любого типа анализа с большим количеством параметров, как это:

Было бы лучше разделить аналитическую возможность на многократные команды, каждого с небольшой группой булевых параметров, такой как

и т.д. Если Вы оказываетесь с параметрами, которые никогда не могут появляться вместе, это - знак, Вы, возможно, должны разбить команду.

Дополнительной информацией не является ошибка.

При получении команды с дополнительными параметрами, Вы не ожидали, просто игнорируете их и не возвращаете ошибку. Точно так же не потрудитесь проверять keyMissedKeywordAttr атрибут события – это больше не служит никакой полезной цели, и всегда возвращает false в Mac OS X 10.2 и позже.

Назад к началу.

Стандартные команды

Стандартный Комплект определяет 15 команд. Приложения должны использовать их в предпочтении к созданию их собственного. Не все команды значимы для всех приложений. Несоответствующие (например, open в приложении без документов, как Установки системы), не должен появляться в Вашем словаре.

В большинстве случаев параметры спецификатора типа могут указать любое число объектов. Убедитесь, что Ваши команды функционируют правильно с исключительным, диапазоном, и every спецификаторы, и что они соблюдают правило списков возврата диапазонов, описанное выше.

Несколько слов о параметрах положения

Несколько команд берут параметры спецификатора расположения типа. Это может быть спецификатором точки вставки или спецификатором контейнерного объекта, и может даже быть диапазоном в большинстве случаев.

Точка вставки является расположением, где может быть вставлен объект: beginning, end, или before или after другой спецификатор. Другой спецификатор может быть диапазоном или every спецификатор, когда работа повторяется для всех получающихся точек вставки.

add photo "On the beach" to end of album "Vacation"
move paragraph 1 to after paragraph 3
make new word at beginning of every paragraph with data "Note:"

Спецификатор контейнерного объекта является контейнером, в котором объекты состоят в том, чтобы быть добавлены, перемещены, сделаны, или что бы то ни было. Приложение выбирает разумное расположение в контейнере. Снова, спецификатор может быть диапазоном или every спецификатор.

add photo "On the beach" to album "Vacation"
duplicate message 1 to every mailbox whose name contains "backup"

Некоторые контейнеры могут принять только контейнерные спецификаторы; посмотрите Объектные Спецификаторы для подробных данных.

добавить

Добавляют указанные объекты к (позиция в a) контейнер и возвращают свои новые расположения. Если to параметр опущен, он выведен из цели. (Например, в tell album "Waterfowl" to add photo 4, to расположение является целью, album "Waterfowl".) Не поддерживают эту команду, если Ваше приложение имеет только непосредственные и связи «один ко многим»; дополнительную информацию см. в отношениях Many-many. Использование диапазона или every спецификатор в to параметр предполагает, что объект может быть добавлен к любому числу контейнеров; это может не быть истиной для всех приложений.

близко

Закрывает указанные объекты. Документы и окна должны быть closeable, если они существуют; приложения могут применяться close к другим объектам также, и может добавить дополнительные параметры.

количество

Возвращает число указанных объектов. Эта команда является исключением к правилу списков возврата диапазонов; count с диапазоном или every возвращает число указанных объектов, который может быть нулем для every спецификаторы. Попытка к count несуществующие объекты являются ошибкой. Используя count с исключительным спецификатором, таким как прозвище допустимо, но не очень полезен, так как оно или возвратится 1 или перестанет работать, если не будет такого объекта. (Сценарии должны использовать exists в таких случаях.) По историческим причинам, count используемый для определения each параметр, но это не было необходимо и было осуждено.

удалить

Удаляет указанные объекты из любых контейнеров, в которых они могут быть и уничтожают их. delete должен всегда удалять объект, никакие вопросы, которые задают. Если Вы хотите иметь мусор некоторого вида (такого как Средство поиска, делает), определите a trash возразите и позвольте пользователям move объекты к нему. В зависимости от прикладной модели, удаляя объект может заставить его контейнер быть удаленным также – для контейнера может не быть возможно не иметь никаких элементов.

копия

Копирует указанные объекты к указанным расположениям, дополнительно изменяя некоторые их свойства с помощью with properties параметр и спецификаторы возвратов для новых объектов. Если to расположение не указано, создайте новые объекты в том же контейнере, соответственно измененном. (Например, duplicate thing "Bob" мог бы привести к новой вещи, названной «копия Боба».) Это не указано, что происходит, если новый объект создал бы конфликт; приложение может просто перестать работать, или оно может разрешить конфликт путем тонкой настройки нового объекта, или оно может определить дополнительные параметры, чтобы указать, как обработать конфликты.

существует

Возвращает true, если все указанные объекты существуют, или ложь, если они не делают. В отличие от большинства команд, указание несуществующих объектов не является ошибкой; это просто означает, что результатом является ложь. Как count, exists исключение к правилу списков возврата диапазонов; спецификаторы диапазона возвращают true, если и только если все объекты в диапазоне существуют, every если по крайней мере один такой объект существует, спецификаторы возвращают true.

добраться

Возвращает значение указанных объектов. Вы не должны определять get в Вашем словаре, так как это встроено в AppleScript. Вы не можете переопределить get с различными параметрами.

сделать

Делает новый объект и возвращает спецификатор ему. at должно быть дополнительным. Если это опущено, выберите разумное расположение по умолчанию – начало или конец текущего документа являются общим выбором. Идеально, with параметры являются дополнительными, но один или другой (но не оба) может требоваться для некоторых классов. Старайтесь различить with properties и with data. Использовать with properties когда Вы переопределяете свойства по умолчанию на созданном объекте приложения. Когда объект эффективно определяется данными из внешнего источника – говорят, строка или файл – использование with data, даже если одно из свойств созданного объекта является (указатель на) теми данными.

переместиться

Перемещает указанные объекты в новое расположение и возвращает спецификаторы для них в их новых расположениях. to параметр всегда требуется и может не быть диапазоном или every спецификатор.

открытый

Открывает указанные файлы и возвращает новые объекты приложения для них – вероятно, documents. Стандартная версия разработана для открытия файлов документов, но могут применяться приложения open к другим объектам и добавляют дополнительные параметры.

печать

Распечатывает указанные объекты. Для большинства приложений объекты всегда являются документами, но это не требуется. Поддержка with properties и print dialog параметры были добавлены в Mac OS X 10.3 (Пантера); см. TN2082 для подробных данных.

выход

Выходит из приложения. Значение saving параметр, который значения по умолчанию к ask, передается любому получающемуся close команды. Приложения, автоматически сохраняющие все, не должны определять saving параметр.

удалить

Удаляет указанные объекты из их контейнера. Если from параметр опущен, он выведен из прямого параметра, если это возможно. (Например, в remove first photo of album 1, from параметр, как понимают, album 1. Однако в remove photo id 437, невозможно сказать, и приложение должно возвратить ошибку.) Не поддерживают эту команду, если Ваше приложение имеет только непосредственные и связи «один ко многим». remove май или может не удалить объект, в зависимости от прикладной модели; см. отношения Many-many для подробных данных. В зависимости от прикладной модели, удаляя объект может заставить его контейнер быть удаленным – для контейнера может не быть возможно не иметь никаких элементов.

сохранить

Сохраняет указанные объекты, возможно в указанном файле. save без in действия как команда меню Save, и могут попросить у пользователя расположения файла; save in с несохраненным файлом действует как Сохранение Как; save in с уже сохраненным файлом действует как Сохранение Копия.

выбрать

Выбирает указанные объекты в пользовательском интерфейсе. Посмотрите Сценарии Выбора для подробных данных о поведении.

набор

Устанавливает указанные объекты в значение и возвращает присвоенное значение, т.е. значение полностью оцененный to параметр. Это - не обязательно та же вещь как исходное значение параметра, в частности если это был объектный спецификатор. В большинстве приложений прямой параметр должен быть спецификатором свойства, так как они не позволяют устанавливать фактических объектов в значения. Вы не должны определять set в Вашем словаре, так как это встроено в AppleScript. Вы не можете переопределить set с различными параметрами.

Назад к началу.

Сценарии представления

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

Сценарии Windows

Как упомянуто в Объектах, окна должны быть индексированы по всей длине, таким образом, window 1 или first window всегда frontmost окно, и window -1 или last window всегда последнее. Это неявно на языке AppleScript, потому что он позволяет front и back как синонимы для first и last, соответственно.

Если у Вас есть больше чем один вид окна – говорят, окна документа и окна палитры – создают отличающийся window подклассы для обработки их. Учитывая спецификатор окна, сценарий должен быть в состоянии определить, какое окно это путем проверки class свойство.

Windows, что объекты модели дисплея должны были соответственно назвать свойства для получения объекта (или объекты), что они выводят на экран. Наиболее распространенный случай этого является окнами документа, которые должны иметь a document свойство, указывающее на документ для того окна. Если существует точно один объект модели для окна, свойство должно быть неявным подконтейнером для окна. (В условиях sdef определите его с помощью a contents элемент.) Тот путь, сценарий может попросить элементы модели окна, не имея необходимость явно проходить через свойство объекта модели. Например, если documents иметь words, тогда get word 1 of window 1 должен работать. Без неявного подконтейнера должно было бы быть сказано в сценарии word 1 of document of window 1. Обратное отношение не рекомендуется; например, документы не имеют окон как неявных подконтейнеров.

Активировать команда

Чтобы активировать окно – т.е. выявить его – используют activate команда и указывает окно. Вызов activate без прямого дополнения должен перенести на следующий период целое приложение. activate должен также работать с объектами, которые являются непосредственные отображенный с окнами, такими как документы. Система автоматически обработает случай, «активируют целое приложение» для Вас, но приложения должны обработать сами другие случаи.

Назад к началу.

Сценарии выбора

Выбор, в сценариях условий, относится только к выбранным объектам модели. Не пытайтесь представлять выбор в диалоговых окнах. Не все приложения должны поддерживать сценарии выбора – для некоторых очень простых, таких как подобные панели управления приложения, это может не быть значимо.

Существует два способа работать с выбором: select команда, и selection свойства. Для обнаружения, что выбрано получите значение selection свойство. Выбрать что-то, также select это, или набор надлежащее selection свойство.

Избранная команда

select, учитывая объектный спецификатор, выберет тот объект в пользовательском интерфейсе и сделает его активным. Это означает

• выявление содержания окна.

• изменение фокуса ввода к надлежащей части окна.

• прокрутка представления так, чтобы объект был видим.

Каждый раз, когда Вы select что-то, надлежащее selection свойства должны изменить на тот же самый что-то.

Свойство выбора

selection свойство является текущим выбором для того объекта. Может быть больше чем один selection свойство в приложении:

• Класс приложений должен всегда иметь a selection свойство. Установка его ведет себя как select команда.

• Если у Вас есть одно окно на документ, и каждый документ поддерживает свой собственный выбор (как, например, TextEdit), то Ваш класс документа должен иметь a selection свойство. Установка его изменяет выбор для того документа, но не изменяет фокус, таким образом, сценарист может изменить выбор неактивного окна, не делая его активным.

• Если у Вас могут быть многократные окна, просматривающие те же объекты модели (как, например, Почта может), то окна должны иметь a selection свойство. Установка его изменяет выбор для того окна как предыдущий случай. Если выбор является просто понятием представления, то класс документа (если таковые имеются) не должен иметь a selection свойство.

Другие объекты, имеющие их собственный выбор, должны также иметь a selection свойство.

Как можно больше, selection свойства должны всегда быть тем же типом имеющим значение: всегда отдельный объект, всегда список объектов, или независимо от того, что является надлежащим. В приложении, имеющем несколько различных видов выбираемых данных, приложение selection свойство будет часто изменять тип; это приемлемо. Например, в Почте, выбор мог быть списком сообщений, списком адресов или текстом.

Выбор текста

В основанной на тексте объектной модели значение выбора является спецификатором, дающим расположение выделенного текста, не фактического текста – например, characters 1 through 3 of document 1, нет "The". Это позволяет сценариям изменяться и что выбрано и выделенный текст (см. ниже), и позволяет им говорить о позициях относительно выбора. Для получения выделенного текста доберитесь contents of the selection.

Если выбор является диапазоном символов, то необходимо возвратить диапазон некоторого вида, такой как characters 1 through 3. (Однако см. следующий параграф.), Если выбор является просто точкой вставки и не содержит символов, то используйте insertion point класс, как показано в таблице ниже.

Некоторые приложения достаточно знают о модели текстового объекта для создания отчетов о выборе с точки зрения модулей, больше, чем символы. Например, если пользователь выбрал третий абзац, selection свойство сообщило бы paragraph 3, нет characters 173 through 254; выбор второго слова того абзаца уступил бы word 2 of paragraph 3. Это поведение мотивируется, но не требуется.

Если Вы поддерживаете непересекающиеся текстовые выборы, то selection свойство должно быть единственным спецификатором, если выбор не является непересекающимся, но должен быть списком спецификаторов, если это. Это повреждается всегда быть тем же типом инструкции по значению, но приводит к менее удивительному поведению в большинстве случаев.

Таблица 10: выбор текста.

(В реальной жизни различные спецификаторы продолжили бы с чем-то как документа 1. Это было удалено для краткости.)

Запись в выбор

Начиная с записи в само свойство выбора просто изменяет то, что выбрано, необходимо записать в свойство или элемент выбора для изменения фактического текста. Как упомянуто выше, selection должен предоставить доступ к подэлементам – в этом случае, characters, words, и т.д. Для достигания целого выбора используйте a contents свойство. Установка свойства или элемента изменяет текст и может изменить продолжительность выбора. Например:

Таблица 11: Запись в выбор.

Перемещение выбора

Текстовая модель позволяет перемещать выбор относительно себя при помощи before и after спецификаторы с помощью выбора в качестве основы. Для выбора точки используйте insertion point класс. Использование beginning и end также позволяется.

Таблица 12: Перемещение выбора

Как указано выше, использование set the selection to имел бы тот же эффект.

Необычные проблемы

Множественные выборы в одном окне

Некоторые приложения имеют многократные представления в одном окне, каждом с его собственным выбором. Например, окна средства просмотра в Почте могут иметь целых три выбора: выбранные почтовые ящики, выбранные сообщения в том почтовом ящике и выделенный текст в сообщении. Только один из них должен сфокусироваться, и это определяет значение selection свойство для приложения и окна в целом. (При наличии затруднений при определении, где фокус, думайте о нем, как будто я выбираю Cut или Copy, какие данные пойдут на буфер обмена?) В таких случаях необходимо добавить дополнительный выбранный thing элементы для достигания различных подвыборов. Например, Почта определила бы типы элемента selected mailbox, selected message, и selected text.

Назад к началу.

Общие советы

Будьте осторожны при многократном использовании кодов.

Если Вы используете тот же термин больше чем в одном месте в Вашем словаре, все они должны использовать тот же 4-байтовый код. Например, если Вы используете input в качестве параметра, снова как свойство, и позже как перечислитель, используют тот же код типа во всех трех местах. С другой стороны, если Вы используете тот же код типа больше чем в одном месте, все они должны использовать тот же термин. Это также применяется к условиям и кодирует наследованный от системы - или предоставленные платформу словари. Например, если Вы определяете a color свойство для класса, его код должен быть 'colr', потому что, именно так это определяется в словаре AppleScript и комплекте сценария NSCoreSuite Какао. Отказ соблюсти это правило заставит Ваши сценарии перестать работать или измениться нечетными способами, когда они будут скомпилированы или декомпилируются – AppleScript изменит исходный срок, чтобы быть последним определенным.

aete словари фактически используют нарушение этого правила для определения синонимичных терминов или кодов. sdef предоставляет прямую поддержку для синонимов с ее элементами синонима; см. sdef документацию для подробных данных.

Не локализуйте свои условия

С одной стороны, основной синтаксис AppleScript ориентирован к английскому языку; наличие идентификаторов на другом языке было бы нечетно. Для другого это, вероятно, не работало бы: идентификаторы AppleScript не могут содержать символы неASCII, который сильно ограничивает то, что можно сказать на большинстве языков.

Назад к началу.

Подсказки для Использования сценариев какао

Какао является средой разработки приложения Apple: это строго объектно-ориентировано, и упрощает добавлять scriptability. Для документации см. Приложения Scriptable. Однако значение по умолчанию Какао, пишущее сценарий поддержки, не следует инструкциям по интерфейсу сценариев во всех случаях. К счастью, существуют обходные решения:

Для всех

Добавьте 'aete' к своему приложению.

Приложения какао в настоящее время определяют свой scriptability путем обеспечения ряда комплектов сценария. Каждый комплект сценария является парой plist файлов, определение комплекта (.scriptSuite) и терминология комплекта (.scriptTerminology). Какао может генерировать aete словарь формата от них, если Вы позволяете ему, но результат имеет тенденцию быть нестандартным, потому что комплекты сценария не могут выразить определенные понятия. (Кроме того, Ваше приложение должно будет быть запущено для получения словаря, имеющего тенденцию раздражать сценаристов.)

Поэтому необходимо создать параллель aete словарь как часть Вашего приложения. Самый простой способ сделать это должно записать Ваш словарь с помощью sdef, и затем генерировать все три файла (.scriptSuite, .scriptTerminology, и aete.r) от него использование sdp(1).

Не требуйте 'в' параметре для, 'делают'.

Из-за ранней ошибки проекта Какао требует at параметр для make по умолчанию. Необходимо всегда переопределять это использование LocationRequiredToCreate атрибут – дополнительную информацию см. в информации о версии Сценариев Какао. Если Вы пишете свой словарь с помощью sdef, sdp(1) добавит корректный атрибут для Вас.

Для амбициозного

Сделайте определенные определения вместо того, чтобы использовать универсальные.

Какао, Пишущее сценарий определений комплекта, испытывает затруднения, будучи абсолютно точным. Определения, которые Вы наследовали от платформ – в частности Стандарт и текстовые Комплекты – почти абсолютно универсальны. Команды, которые не поддерживает Ваше приложение, являются все еще видимыми, прямыми параметрами, определяются как просто ссылка типа, и application имеет document элементы, нужны ли этому они или нет. Можно работать вокруг этого путем создания aete словарь для Вашего приложения (см. выше), но это - больше работы. Если Вы используете sdef для генерации Вашего aete, необходимо будет изменить sdef версию Стандартного Комплекта (/Developer/Examples/Scripting Definitions/NSCoreSuite.sdef), так как это в настоящее время будет иметь ту же проблему.

Обеспечьте хорошие сообщения об ошибках.

Сообщения об ошибках Сценариев какао по умолчанию записаны в универсальном programmerese (таком как NSReceiverEvaluationScriptError: 4), а не определенный английский язык (тот, который не Может получить окно 17). С Mac OS X 10.3 (Пантера), можно установить собственные коды ошибки и сообщения путем вызова [NSScriptCommand currentCommand] и затем вызов -setScriptErrorNumber: и -setScriptErrorString: на возвращенном объекте. См. документацию NSScriptCommand для получения дальнейшей информации.

Назад к началу.

Ссылки

• Страница разработчика AppleScript

• AppleScript на Mac OS X

• Документация AppleScript

• Приложения Scriptable

Назад к началу.

История версии документа