• Choose a category
• All
• Classic-Fiction

By Root 1484 0

can see, we have accessors for our name instance variable. We also have a pair instance variable in the Person class, plus there is a pairs array in MyObject. It happens that the rest of our implementation is as follows. A Pair has two Person pointers, called person1 and person2. To pair two Persons, we make a new Pair object, add it to the pairs array, and point its two Person pointers at the two Persons; we also point the pair pointer of each of these paired Persons at this Pair object. Thus, a Pair and its Persons are double-linked; a Person knows it is paired because its pair instance variable isn't nil, and it can find the Person to which it is paired by looking at its Pair's Persons and finding the one different from itself.

The question of whether this way of implementing pairings is a particularly good one is beside the point. What's important is that we do not intend to expose this to the end user. You don't have to show the user everything that goes on behind the scenes! The end user will be thinking in terms of persons, not pairs, and we want our scripting interface to match the user's conceptual thought processes, not to reveal our backstage implementation.

So how should our scripting interface look to the AppleScript programmer? Clearly there needs to be a person class, and a person should have a name property. There can be multiple persons, so there should be a persons element. This is not a document-based application, so the only coherent location for the persons element is at the top level of the object model—that is, it will be an element of the application class.

Now we'll create our sdef-format dictionary and add it to the project. The best way to make the dictionary is with the wonderful Sdef Editor application (see Appendix C for this and other Cocoa scripting resources). Let's call the dictionary pairs.sdef. Then to make our application scriptable through this dictionary, we must add the following lines to our project's Info.plist file:

NSAppleScriptEnabled

YES

OSAScriptingDefinition

pairs.sdef

The first step in creating an sdef is to give it whatever common commands we intend to implement. For example, we want the user to be able to ask how many persons there are, using the count command. This won't be possible all by itself; we have to include the count command in the dictionary. Common commands can be found in the Standard Suite (see "Suites" in Chapter 20), which you can access in Sdef Editor by choosing File → Open Standard Suite → NSCoreSuite. The idea here is to put NSCoreSuite into the dictionary and then immediately remove from it everything we don't need; in this case, the remaining commands will be just count, delete, exists, and make—the bare minimum needed for working with a collection of persons. (There is no need to include get and set, because they are short-circuited, and we don't need an entry for quit because every application can do that.)

Now we make a new suite, which I'll call the Pairs Suite. I like to move the application class into this, and I'll simplify the application class, leaving just the name, frontmost, and version properties, which are implemented automatically. Now we can add the person class with its name property, and give the application class a person element.

I assume you can figure out how to work with Sdef Editor, so let's focus on the text version of the result. I'll present it in two parts. First we have the automatically generated Standard Suite:

description="Common classes and commands for most applications.">