AppleScript_ The Definitive Guide - Matt Neuburg [71]
Compiled Script Files as Script Objects
A script can read a compiled script file and incorporate its contents as a script object. Similarly, a script can save a script object out to disk as a compiled script file. You might use this mechanism as a means of implementing file-level persistence, or to build a separate library of commonly needed code that all scripts can share.
The mechanism depends upon three verbs. They're not part of AppleScript proper, but are implemented in a scripting addition (Chapter 3) that's standard on all machines.
Reference Section
Reference Section
Reference Section
(On aliases and file specifiers and the differences between them, see Chapter 13. The verb run script, instead of a file, can take a string, and it then functions as a kind of second level of evaluation; see Chapter 19.)
When you save a script object with store script, the lines delimiting the script object definition block (if any) are not included. This fact makes sense, since those lines were never part of the actual script object to begin with. So, for example:
script sayHello
display dialog "Hello"
end script
store script sayHello in file "myDisk:myFile.scpt" replacing yes
What is saved in myFile.scpt is the single line:
display dialog "Hello"
Data Storage
Recall from earlier in this chapter that top-level script object entities are persistent, but that at the level of a file on disk, this persistence is unreliable, because it depends upon the environment where the script runs. For example, Entourage's Script menu doesn't save a compiled script file back to disk after execution, so top-level entities don't persist between executions. We can get around this uncertainty by storing needed data ourselves in a separate compiled script file. A script object that we save with store script is saved along with the current values of its top-level entities. Thus we can guarantee file-level persistence by saving a script object as a compiled script file separately from our main script.
Tip
If you load a script as a script object with the load script command, and top-level entity values within this script object change, and you wish to write these changes back to disk, it is up to you do so explicitly, with store script.
The run script command does not save its script, so any changes in the script's top-level entity values do not persist.
Here's an example where we display the user's favorite color. This information will be stored persistently in a file on the desktop called myPrefs.scpt. (The path to command is discussed in Chapter 21.) First we try to load this file. If we succeed, fine; if we fail, we ask for the user's favorite color and store it in myPrefs.scpt. Either way, we now know and can display the user's favorite color. If the user doesn't move myPrefs.scpt, the next time the script runs there will be no need to ask for the user's favorite color; we will already know it.
set thePath to (path to desktop as string) & "myPrefs.scpt"
script myPrefs
property favoriteColor : ""
end script
try
set myPrefs to load script file thePath
on error
set favoriteColor of myPrefs to text returned of ¬
(display dialog "Favorite Color:" default answer ¬
"" buttons {"OK"} default button "OK")
store script myPrefs in file thePath replacing yes
end try
display dialog "Your favorite color is " & favoriteColor of myPrefs
You might object that a file sitting on the user's desktop is a silly place to store our data. You're perfectly right; it's only an example! How might we solve this problem in real life? We need a place to put the data where the user won't see it or object to it. One solution, if it is supported by the environment where the script will run, would be to make this script a script bundle