A.3. Conclusions, Lessons, and Advice You'll no doubt have noticed that most of my time and effort working on this problem was spent wrestling with the particular scriptable application I was trying to automate. In general, that's how it is with AppleScript. AppleScript itself is a very small language; it is extended in different ways by different scriptable applications. Trying to work out what a particular scriptable application will let you say and how it will respond when you say it constitutes much of the battle of working with AppleScript. Another feature of the struggle is that AppleScript's error messages aren't very helpful, and it lacks a debugging environment (unless you use Script Debugger as your script editor application), so it's important to proceed with caution and patience. When you try to execute a script, all you really know is that it worked or it didn't; if it didn't, finding out why isn't easy. You can see that I developed my final script slowly and in stages, testing each piece as I went along. I knew that the pieces worked before I put them into place; that way I could be pretty confident that I knew what the script as a whole would do. Here, to conclude, are a few apophthegms to live by, derived from the foregoing. I hope you'll find this advice helpful in your own AppleScript adventures:
Use the dictionary. The biggest problem you face as you approach driving a scriptable application is that you don't know the application's "object model"what sorts of thing it thinks of itself as knowing about, what it calls these things, and how the things relate to one another. In this regard, nouns (classes) are much more important than verbs (commands). Most scriptable applications, especially if they are scriptable in a deep and powerful way, have lots of nouns and relatively few verbs. Notice how I did almost everything in the script with the basic built-in verbs get, set, and count; even select is fairly standard. The only unusual verb I ended up using was find. I spent almost all of the time worrying about the nouns. The biggest problem in AppleScript is referring to the thing you want to talk about, in the manner that your scriptable application expects and accepts.
Don't expect too much from the dictionary. Try to think of other ways to learn how to construct the desired reference. FrameMaker's dictionary let us down quite severely on several occasions; I was much more successful in asking for the selection and letting FrameMaker describe a thing in its own terms than in trying to construct a reference from scratch based on the dictionary. In fact, although I didn't say anything about it at the time because the matter is rather technical, FrameMaker's dictionary is massively faulty; although I learned by experiment that an anchored frame can be an element of a paragraph or of a document, the dictionary doesn't say this at all. Had it done so, I would have had a much easier time.
Think outside the box. When FrameMaker wouldn't just hand me references to every anchored frame in the order in which they occur in the document, I was frustrated, but I didn't give up; I tried to think of another way. The find command looks broken to me, but I didn't worry about this; I figured out how to move the selection point forward to work around the problem. If you waste your time and energy bewailing things that you feel are broken or quirky or inadequate in AppleScript or in some particular scriptable application, you won't get any work done. Face reality and tighten your belt another notch.
Start small. Look at how much of the time was taken up testing very short snippets of code over and over just to learn how to construct a reference or to see what some operation would do. Part of the problem here is that you don't know until you try it what an application will permit you to do; the dictionary can't really tell you. Another part of the problem is that AppleScript has no built-in facilities for debugging. Therefore you need to develop the program one line at a time, building it up from individual lines that you already know work (because you've tested them). Don't try to write an entire program in AppleScript and then figure out why it didn't work; you'll never manage it. By the time you put the whole program together, you should be like a lawyer cross-examining a witness in court: ideally, you should never ask a question to which you don't already know the answer.
Test every step. When you don't know the answer to some question your code is asking in the course of your script, find out. Use the result of running a script. Use logging . You want to know at every step, as you develop a script, whether what's happening is what you want and expect.
Don't be ashamed to experiment. Don't be afraid to guess! A lot of AppleScript code development is guesswork. As Aristotle said, it is a mark of wisdom to ask from a subject only so much precision as that subject admits of.
Solve the single case before expanding to "every." Solve the single case before expanding to a loop. Solve an artificial loop before worrying about the boundary cases (that is, before figuring out how to know exactly how many times to loop).
Don't try to understand AppleScript's mysterious error messages. The important thing isn't what went wrong but where it went wrong. Knowing where the problem is will usually suffice, because you know where you need to make a change, even if you're just guessing when you make it. If you think the error isn't important, use error-handling (a try block) to ignore it, so that it won't stop your code from executing.
Write a practice script before writing the final version of the script. AppleScript has the power to do very far-reaching things, such as deleting files and wrecking your document. You want to be very sure things are working before you throw the switch that says, "This is not a drill."
Know the language. It's true that in the course of development I did a lot of guessing about FrameMaker's object model, but I didn't guess about the language itself. I couldn't have written this program at all if I hadn't known already what my and it mean, and how to use tell and of, and how to form a boolean test specifier, and what the difference is between a property and an element. AppleScript may look like English, and that might make you think you already know AppleScript because you already know English. If you think that, you're wrong. AppleScript is a rule-based programming language like any other. It is rigorous, choosy, and precise. This book can't teach you to write that one special script you'd like to write, but it can and does teach you the language.
|
