While old-fashioned macro recording utilities were quite useful in their time — they could simulate a series of literal keystrokes and mouse clicks, respectively — it was difficult to use them in a dynamic and practical manner. With AppleScript you can not only automate a sequence of literal actions, but also you can create a dynamic script that includes logical branches, variable content, and options for different behavior depending on specific conditions. This gives AppleScript the power of a real programming language.
AppleScript possesses more unique characteristics that add to its appeal, such as its English-like syntax, the fact that it is universally open-ended, its deep level of access into the Mac OS framework and the frameworks of third-party applications, and its consistency between OS updates.
English-Like Syntax
One of the most unique characteristics of AppleScript is its English-like syntax. While some detractors might say it is not even close to "natural spoken English," most would agree that it is certainly more like a spoken language than most other scripting and programming languages. The difference in syntax can be illustrated with a few simple examples.
The following examples present a sort of Rosetta Stone of programming languages. The code in each example performs exactly the same function: It builds a text-based list of numbers within a range specified by two variables. At the end of each script, the resulting value will be a sequence of numbers from 25 to 30 with a carriage return after each number.
Listing 1 illustrates the English-like language used in AppleScript. Notice how setting the content of a variable doesn't require any code-like declarations or explicit identification of the initial value's data class. Also, there is no need to worry about line endings; just type a return and keep on typing.
Listing 1: AppleScript
set numLength to 5
set numStart to 25
set textResults to numStart as string
if numLength > 1 then
repeat with a from 1 to numLength
set numStart to numStart + 1
set textResults to textResults & return & numStart
end repeat
end if
The code script shown in Listing 2 performs the same functions with JavaScript. Putting a value into a variable is a little less English-like. Like many other languages, JavaScript requires a special line ending, which in this case is a semi-colon. Also, the repeat loop is more cryptically phrased and, therefore, less clear than the AppleScript example.
Listing 2: JavaScript
var numLength = 5;
var numStart = 25;
var textResults = numStart;
for (var a=numStart+1; a<=(numStart+numLength); a++) {
textResults=textResults + '<br>' + a;
}
The code in Listing 3 performs the same functions using the REALBasic language. Notice that the variable declarations are more complicated and require the data class of each must be specifically stated prior to placing a value within them.
Finally, the code shown in Listing 4 performs the same functions with PHP (Hypertext Preprocessor). Like JavaScript, it requires line endings and brackets enclosing a more cryptic combination if-then and repeat function.
Certainly, the development time required to build a script always depends on the complexity of the tasks to be automated. However, AppleScript's English-like language and automatic handling of many fundamental programming chores significantly reduce the time required to develop a solution.
Universally Open-Ended
Another important characteristic of AppleScript is its success as an open-ended, universal scripting language. Before AppleScript, the few applications that enabled users to automate tasks each had their own way of doing things. In today's modern Internet-driven world full of standard languages, it is hard to imagine a time when each application had its own set of rules. Imagine a nightmarish world in which every Web site had its own language and, therefore, its own browser. Perhaps that is a bit dramatic, but that is not totally unlike the way things were with automation.
In a world without AppleScript, each application would need its own macro language and features. To use them, you would have to learn and remember each of them from any number of applications. Creating a macro that works across multiple applications would be difficult to virtually impossible. Some software might try to bridge this gap, but it could break with each OS upgrade and generally would be more trouble than it's worth.
AppleScript addresses such nightmares by implementing a universal language with which any and all applications could communicate. An application possesses its own object model that can be automated by AppleScript, specifying the objects, properties, and commands that it can work with. In a way, each application's script dictionary becomes an extension of the AppleScript language, offering its unique services to a script in a familiar way.
Today, virtually every application developed for the Mac has some scriptable features. Widely used applications like Adobe's Creative Suite have extensive support for automating almost every conceivable feature. For those applications that don't support scripting, or to access a command not made accessible to AppleScript, Apple developed System Events. This amazing scripting addition enables AppleScript to simulate mouse clicks, keystrokes, and menu selections in many un-scriptable applications, thereby allowing you to script the un-scriptable.
Deep Level of Access
AppleScript enables scripts to tap into many of the technologies of Mac OS X with its unique ease of use. For example, the do shell script command in the Standard Scripting Additions enables a script to run any shell script.
AppleScript also has access to many of the frameworks created by Apple for their applications and for third-party developers. These are made available to scripts with Scripting Additions. The Image Events scripting addition enables scripts to access the Core Image framework of the OS. Also, soon after the Core Data framework was developed, the Database Events scripting addition became available.
Consistency Maintained between Updates
Because AppleScript is built as a clean and easy-to-use layer on top of the OS that obscures the complex connection to the lower-level architecture, scripts typically continue to work from one OS update to the next. While major OS changes typically require bug fixes or complete overhauls of third-party applications, scripts are usually immune to such things. Even the transition from the "Classic" OS (System 9) to Mac OS X didn't require much more than a recompiling and resaving of older scripts.
When third-party applications require major rewrites or make changes to their object model and command libraries, it can break scripts. However, most applications eventually maintain a relatively consistent language for objects, their properties, and the commands they support.
No comments:
Post a Comment