Избегать AppleScript через Ruby: rb-appscript или rubyosa?

Question

Избегать AppleScript через Ruby: rb-appscript или rubyosa?

Привет, коллеги по Mac, рубинисты и ненавистники AppleScript,

Для тех из вас, кто имеет опыт работы как с rubyosa, так и с rb-appscript, я хотел бы услышать плюсы и минусы каждого из них, который вы решили придерживаться, и какой вы бы порекомендовали для совершенно не разбирающегося в AppleScript Рубиновый старожил. Кроме того, есть ли другие варианты, которые я пропустил?

Кроме того, любые советы, касающиеся стороны AppleScript уравнения (например, просмотр словарей и т. Д.) Также приветствуются.

Просмотр некоторого примера кода также очень помогает.

16

ruby macos applescript rb-appscript rubyosa

Источник

user13989 21 авг '09 в 03:24

4 ответа

Решение

user136334 22 авг '09 в 17:47 2009-08-22 17:47 · Accepted Answer · 2009-08-22 17:47

Квот кч:

Это хорошо, но теперь мне интересно, как скриптовый мост сравнивается с яблочным скриптом. Я думаю, у меня будет кое-что почитать.

SB опускает некоторые функции, найденные в AppleScript. Например, следующий скрипт перемещает все файлы с рабочего стола в папку "Документы":

tell application "Finder"
   move every file of desktop to folder "Documents" of home
end tell

В SB класс SBElementArray строго ограничивает вашу возможность применять одну команду к нескольким объектам, поэтому вам нужно либо обратиться к низкоуровневому API, либо получить список отдельных ссылок на файлы и перемещать их по одной за раз:

require 'osx/cocoa'; include OSX
require_framework 'ScriptingBridge'

finder = SBApplication.applicationWithBundleIdentifier('com.apple.finder')
destination = finder.home.folders.objectWithName('Documents')
finder.desktop.files.get.each do |f|
   f.moveTo_replacing_positionedAt_routingSuppressed(destination, nil, nil, nil)
end

В rb-appscript вы бы использовали тот же подход, что и AppleScript:

require 'appscript'; include Appscript

app("Finder").desktop.files.move(:to => app.home.folders["Documents"])

...

SB запутывает механизм событий Apple гораздо сильнее, чем AppleScript. AppleScript может быть болезненным, чтобы разобраться, со странным синтаксисом, склонностью к конфликтам ключевых слов и тому подобным, но помимо этого он в значительной степени представляет события Apple как есть. Единственное действительно важное чудо в AS - это его неявное получение, когда он оценивает буквальную ссылку, которая не появляется в качестве параметра команды. Самым большим грехом AppleScript является то, что его документация лучше не объясняет, как он на самом деле работает, но есть очень хорошая статья Уильяма Кука, которая проливает много света на то, что на самом деле происходит.

SB, с другой стороны, делает все возможное, чтобы притвориться, что это настоящий API-интерфейс Cocoa с поведением в стиле Какао, так что накапливается большое количество волшебства. Результатом является что-то внешне привлекательное для разработчиков Какао, но как только эти абстракции начинают протекать - как неизменно делают абстракции - вы полностью находитесь в море с точки зрения понимания того, что происходит. Например, SBElementArray утверждает, что является массивом - он даже подклассов NSMutableArray - но когда вы на самом деле пытаетесь использовать его методы массива, половина из них работает, а половина - нет. На самом деле, это совсем не настоящий массив; это обертка вокруг неоцененного спецификатора объекта события Apple, выдуманная, чтобы притвориться, что это NSMutableArray. Поэтому, когда он делает что-то не похожее на массив, вы в значительной степени разбираетесь в понимании причины. И, как упоминалось в #1, некоторые из этих толстых абстракций затрудняют доступ к стандартным функциям событий Apple под ними.

SB в первую очередь пытается быть хорошим API Какао, а не хорошим API событий Apple, и в итоге тоже не очень хорош.

Между прочим, AppsScript следует примеру AppleScript и использует противоположный подход: правильно проводите мероприятия Apple, а затем беспокойтесь о приспособлении к языку хоста. Вот почему некоторые люди предпочитают RubyOSA над rb-appscript; Хотя appscript- более эффективное решение, если вы работаете с объектно-ориентированным фоном, это будет выглядеть очень странно. Это связано с тем, что в событиях Apple используется парадигма, основанная на запросе RPC-плюс, и любой сценарий сходства, который может потребоваться для ООП, является чисто синтаксическим. Ближайшая аналогия - отправка XQueries через XML-RPC, и к этому нужно привыкнуть.

...

SB, как правило, страдает значительно больше проблем совместимости приложений, чем AppleScript.

Некоторые из этих проблем связаны с тем, что SB навязывает свои собственные идеи о том, как Apple Event IPC должна работать поверх того, как он на самом деле работает. Например, SB создает набор [псевдо] прокси-классов, представляющих классы, определенные в словаре; затем он накладывает различные ограничения на то, как вы можете взаимодействовать с этими объектами, основываясь в основном на классических объектно-ориентированных поведенческих правилах.

Например, следующий скрипт получает имена всех подпапок папки Documents:

tell application "Finder"
   get name of every folder of entire contents of folder "Documents" of home
end tell

Если вы попробуете такой же подход в SB:

finder.home.folders.objectWithName('Documents').entireContents.folders.arrayByApplyingSelector(:name)

он доходит до метода #folders, а затем выдает ошибку, потому что тип свойства 'full contents' в словаре Finder объявлен как 'reference'. Поскольку в словаре не определен "ссылочный" класс с элементами "папка", SB не позволяет вам создать этот конкретный запрос (если только вы не хотите перейти к низкоуровневым API и использовать необработанные коды AE). Это совершенно законно в соответствии с правилами событий Apple, но не вписывается в более узкий OO-ориентированный набор правил, наложенный SB.

Другие ошибки происходят из-за предположений SB о том, как приложения с поддержкой сценариев будут реализовывать определенные команды и другие функции. Например:

tell application "iTunes"
   make new playlist with properties {name:"test 1"}
end tell

SB не позволяет вам использовать любые ярлыки, предоставляемые iTunes (вы можете опустить ссылку на исходный объект, в котором вы хотите создать плейлист, в этом случае используется основной источник 'Library'), поэтому давайте напишем это в полный для лучшего сравнения:

tell application "iTunes"
   make new playlist at source "Library" with properties {name:"test"}
end tell

В SB вы бы написали это так:

itunes = SBApplication.applicationWithBundleIdentifier('com.apple.itunes')

playlists = itunes.sources.objectAtIndex(0).playlists()
newplaylist = itunes.classForScriptingClass(:playlist).alloc().initWithProperties({:name => 'test'})
playlists.addObject(newplaylist)

Однако, когда вы запускаете его, он раздражает #addObject. В своей попытке превратить одну команду "make" в многострочное упражнение, SB предполагает, что параметр "at" всегда будет ссылкой на форму "end" of