Chapter 6: continued

Special Locations for Scripts

As discussed in Chap 3, scripts that you write (and custom data that you create) generally should go in your people.XXX table. While not required, this organization has proven to be very useful for keeping track of your work and sharing with others.

Sometimes there are important reasons for putting scripts elsewhere. Frontier has a number of special tables, i.e. locations in the Object Database. When you add scripts to any of them, you may want to make a note in the notepad ("Open Notepad" from the "Custom" menu, or Cmd-Y). Here is an overview of some of these tables.

Many of Frontier's web publishing features depend on the user table; see the Frontier website for details.

You can have Frontier run scripts when it first starts up; simply place them in the system.startup table. Similarly, scripts placed in system.shutdown will run when Frontier shuts down -- e.g. after you select Quit from the File menu. In both cases, the scripts run in alphabetical order.

Frontier agents (background processes) must live in the system.agents table. Refer to Chap 10 for details.

Experienced script writers who want to share a collection of scripts, data and one or more custom menus may create a "suite" in the suites table. Suites are discussed in Chapter 10.

Frontier's menubar is stored at system.misc.menubar; feel free to customize it. One approach that works well for many people is to create a new menu, perhaps named with your initials. Keeping all of your additions in one place makes it easy to figure out what is yours and what ships with Frontier, to smooth the process of sharing with others and tracking changes that may be made to Frontier in the future.

The system.misc table contains other interesting scripts that advanced script writers may want to customize. Make a backup first! (Just copy and paste the original before making changes; it will be in the table in case you need it.)

Scripts that call the built-in functionality of scriptable applications -- sometimes called "glue" scripts -- can be found in system.verbs.apps. (See Chap 5.)

Many scriptable applications support Frontier menu-sharing. These custom menus are stored in the system.menubars table; the names correspond to the 4 character application ID (also known as the file's "creator" code). Feel free to change them. Don't forget to keep a copy, that will make it easier to upgrade to changes from the author or developer.

Scripts that call Frontier extensions called UCMDs (UserLand Commands) are stored in the system.extensions table. In addition to the UCMDs written by UserLand and others, many AppleScript "Scripting Additions" (OSAXen) can be automatically converted into UCMDs and loaded into the extensions table. See the Frontier website for details.

Although Frontier is already scriptable, advanced script writers can add custom events and scripts to handle them. These scripts are stored in system.verbs.traps.

One word of caution: although sometimes there is no good alternative, we recommend that you do not edit Frontier's built-in verbs, Frontier suites or application "glue" scripts. If you write other scripts that depend on the changes and then the original author or developer releases a new version, you must either make your changes again or stick with the old version and miss out on the author's improvements. Further, if you want to distribute your scripts, you would force everyone else to make the same changes. Instead of modifying the original, just create your own version in your People table. If you want to distribute your scripts to others, just include these extra scripts.

Information On Each Object

Every object in the Frontier Object Database, regardless of type, has three pieces of information stored, corresponding to the three columns in the table:

• name
• value (or contents)
• kind (datatype)

Every object must have a name. You normally use the name of an object to access its contents, although as we will see in the next section you can use its relative position in the table when that information is known and useful. A Frontier object's name must not be longer than 32 characters. While most of the names you'll see in the Object Database are one word, this is not mandatory. Multi-word names are perfectly legal. As we'll see in the next section, they add special addressing requirements for scripts but nothing insurmountable.

What is displayed in an object's value column depends on two factors: the kind of data involved and, if it is non-scalar, whether it has been loaded from the disk during the present session. For example, take a look at Figure 6-3, which is part of the root.examples table as it is shipped by UserLand.

Figure 6-3. Partial Listing of examples Table

Notice that the objects called list1 and list2 are outlines and are stored on disk. The object lunchReminder is a word processing text object that is also on disk. But mouseat is a scalar object, a point, and its value is reflected directly in its entry in the table. Similarly, name is a scalar object, a string, so its value is shown in the table. (Note that the item markers for scalar objects are gray.)

Double-click the item marker beside list1 to open it. Now look at its entry in the examples table. It indicates the contents of the outline as far as Frontier knows them at this point, namely that the outline has five lines.