Apple Script

AppleScript is Macintosh and MacOsx technology for automating tasks within AppleScript aware applications and for communicating between AppleScript aware applications. It employs a somewhat English like syntax (see also HyperCard) and is the bomb. A weakly promoted killer Mac feature...

The key ideas behind AppleScript are the OpenScriptingArchitecture (OSA) and the AppleEventObjectModel. The OpenScriptingArchitecture defines generic interfaces for integrating scripting languages ("scripting components") into the system.

The integration goes in both directions: applications can execute scripts written in any installed language, without having to know which language it actually is. Scripts can control applications.

Control of applications works via the AppleEventObjectModel. The AppleEventRegistry? contains "suites" for several application domains. There's a core suite for basic control that's appropriate for every application. There's a suite for text processing and more specific suites for mail and tabular data. In a sense, these are precursors to the DocumentObjectModel.

The AppleEventObjectModel also supported very expressive semantics for selecting objects, which to continue the analogy would be a precursor to XpathLanguage. However, it was up to applications to implement those semantics, and implementations varied, leading to AppleScript developing a bit of a reputation as a ReadOnlyLanguage.

This is really old stuff by now available in the MacOs since around 1992. Unfortunately, whereas programming in AppleScript is pretty easy, programming for AppleScript, that is making an application really AppleScript-savvy, is unproportionally complicated. A lot of applications only have very basic AppleScript-support if they have it at all. Notable exceptions are, if I remember correctly, QuarkXPress, Adobe Golive (nee Golive Cyberstudio), an early version of Excel. Also BbEdit

This is no longer really true after MacOsx. Making a Cocoa application scriptable mainly involves exposing method names in an XML PropertyList?

Also, unfortunately, the promise of multiple scripting languages was never fulfilled. Apart from AppleScript, only UserTalk?, the language in UserLandFrontier, fully supports the AppleEventObjectModel. Not true, there is also a port of the SpiderMonkey JavaScript engine to OSA.

-- MichaelSchuerig

AppleScript has had some interesting innovations lately. Recent versions of MRJ (Macintosh Runtime for Java) on MacOs 9 allow AppleScript to control Java applications -- the Java objects and methods of a running Java application can be made visible to AppleScript as objects and events.

On MacOsx 10.1, AppleScript supports SOAP and XML-RPC (http://www.apple.com/applescript/macosx/web_services/). Also, Cocoa applications may be getting scriptability for free, with AppleScript support built into the latest Cocoa libraries.

AppleScript is the only ScriptingArchitecture? that I know about that allows recording. An application is recordable when all (or most) user-interface handling results in the generation of one or more AppleEvents, which are directly routed to the application itself for execution. The AppleScript system can record these AppleEvents in a script, which the user can then edit. This can be a very user-friendly way for a user to start scripting, but of the relatively few applications that support AppleScript, even fewer support recordability.

Applications that are scriptable, but not recordable, have an architecture something like this: 

 [GUI] ---> commands ---> [Model] <--- commands <--- [ScriptingEngine] <--- Scripts or AppleEvents
but recordable applications have an architecture like this: 

 [GUI] ---> AppleEvents ---> [ScriptingEngine] ---> commands ---> [Model]
Can anyone describe how recordability can be implemented in C/C++ or Java applications via SOAP or XML-RPC, or Python, or JPython?

Would Python- and JPython-embedded applications have to generate Python source code, to implement the recordability pattern shown above?

-- KeithRay

Recordability could be implemented in other languages and other operating systems just as the are for the Apple event model. Recordability is not an attribute of AppleScript--it is a property of the way that Apple events work. To implement recordability, you have to generate an "event" in a standardized format for every one of your application's scriptable actions and send them all through a standard channel. Then the "recorder" just has to examine each event that passes through the channel, and output it in the scripting language format. This mechanism is easy to implement in any programming language (assuming you already have scripting built in to an application).

But the fact that so few Macintosh programs support recordability is a good indication of how difficult it is to design an entire application around this architecture. To make it happen, you have to have a strict separation between user interface (which generates the events) and the backing model (which consumes the events), and you need to spend a lot of time designing your event model so that they work as desired no matter whether they are generated by UI or by scripts. Everyone agrees this is a good idea, but very few people actually take it to the necessary extreme.

-- KrisJohnson

Ah... but tools can be (and should have been) created to do all dirty work for the developer. The amount of hand-coding required to use AppleScript/AppleEvents in C or C++ is truly horrendous. PowerPlant makes it a little easier, but not much, and MacApp ACS offers some classes that similar to what I wrote myself.

My team and I have wrapped AppleEvents and Java classes via JNI for a MacOs C++ application using very similar sets of classes [kind of opposite of SimplifiedWrapperAndInterfaceGenerator, which makes C/C++ code accessible from Java]; if we added a parser for an IDL, we could generate the necessary code at will (but instead we hand-coded it).

I should be able to take an IDL file describing my core "model" objects, annotated with suggestions for what the AppleScript equivalents should be (as in applescript "use several words" versus C++ "UseServeralWords?"). The tool should generate C/C++ code to translate AppleEvents into calls to my model objects (and handle return values), and generate the AppleScript vocabularly resource (there's no reason the tool couldn't generate sample AppleScripts as well.)

My team is make a Windows application scriptable and recordable using COM, ATL, MFC. Our app is scriptable from VisualBasic, JScript, VBScript, etc. using COM, and the VC++ IDL files in the project specify the alternative "vocabulary" used by the scripting languages to access methods of our core classes.

One interesting testamony to the power of ObjectiveCee/Cocoa on MacOsx, is that Cocoa apps are getting scriptability for free -- the developers don't have to do anything, as far as I can tell. Java apps under MacOs 9 also had some free scriptability via MRJ.

--KeithRay

AppleScript now has its own xUnit TestingFramework, AsUnitForAppleScript.

--AnthonyAdachi

Examples: 

 tell application "Finder" 
   activate 
   select file "partenariat.pdf" of disk "demo" 
   open selection 
 end tell




 tell application "Finder"
   ignoring application responses
     quit
   end ignoring
 end tell


 repeat with i from 1 to 10000
 end repeat


 display dialog "Wait till your computer ceases all activity." & cr & "Count to 10." & cr & "Press option-Command and hit OK. Keep keys pressed till Finder restarts."


 ignoring application responses
   tell application "Finder"
     activate
   end tell
 end ignoring
 quit

CategoryScripting

EditText of this page (last edited June 22, 2014) or FindPage with title or text search