Chapter 6

The Object Database

This chapter describes the Frontier Object Database in detail, including:

• how it's organized
• how to address objects stored in it
• how to find objects stored in it
• variable and the Object Database
• how to export information from it and import information into it
• how to use it for personal information and make it your own

Introduction

The Object Database is a table that can hold many different types of information, including other tables. The most common and important datatypes are defined on the "Kind" popup menu in the Object Database editing table.

The first seven datatypes are "scalar" (simple) values. You can edit their contents directly in the table window in which they are located. The item marker on scalar objects will always be gray since the item does not lead anywhere; there is no further window that can be opened to view the item. The Zoom button will also be gray.

boolean
character
number (long integer)
float (floating-point number)
date
direction
string

Other datatypes are more complex and have require their own special editing windows. The item markers for these objects is always a full triangle, solid black if it is the currently selected object in the table, outlined if it is not.

word processing text
picture
outline
script
menubar

Clicking the Zoom button or double-clicking on the item marker of a complex Frontier object opens the editing window for that object and makes that object the current selection in its table. Navigating in Object Database windows is discussed further in Chapter 7.

Few scripting or programming environments have anything like the Object Database. Key features include:

• stores contents permanently
• is hierarchic
• can be accessed interactively, from a script or from an external program written in a conventional programming language like C or Pascal

Organization of the Database

Figure 5-1 shows you the top part of the hierarchy that makes up the Frontier Object Database as delivered by UserLand. When you use this database, import scripts and other objects into it, and otherwise customize it, this organization changes, of course.

Figure 5-1. Partial Object Database Hierarchy

As you can see, the base table in the Object Database is called root (like the root of an upside-down tree). It has eight items in it: seven tables and one word processing text entry (the "readme" object). Each of the seven tables, in turn, has one or more elements, some of which may be further tables. This nesting of sub-tables can continue up to 25 levels deep in the database, though as a practical matter you'll probably find that objects nested deeper than 7-10 layers may become cumbersome to use.

Sub-Tables in root

You probably won't have much occasion to make changes to most of the tables that make up the Object Database. Later in this chapter, we'll take a look at some special places where you may want to store scripts. For now, let's look at the tables stored in the root table of Frontier (plus one extra).

Examples

The examples table holds several dozen examples of objects and scripts that are used extensively in this manual and in DocServer. In addition to browsing the table and looking at the scripts, you can also search to see if there are examples for a particular verb or topic of interest.

Suites.samples

Many new example scripts are in the "samples" table, a sub-table of "suites" (described shortly). Samples in turn has sub-tables, organized by topic or application. When you are learning Frontier, you might want to go through a few of these scripts every day or week. Even as you become comfortable with Frontier, look back occassionally; you may be surprised at what new things you discover.

Helptext

Contained in the helptext table are a number of outlines and word processing text objects whose purpose is to provide context-sensitive help with various operations in Frontier. Many of these objects are opened in response to your actions at various points in Frontier. But you may find them useful to open directly as well.

People

The people table is one you'll see frequently. When you run Frontier for the first time, it asks you for your name and initials. Among other initialization it performs at that point, Frontier creates a new entry in the people table with your initials. For example, if your name is Xenophanes Xerxes Xenophon, and if you enter your initials as "XXX," Frontier creates a table entry called people.XXX. (This manual often refers to people.ME.) The People table is the primary place for you to add scripts and data.

Note that Frontier registered your People table in its paths table, so you refer to any object it contains by cell name without the people.XXX portion of your address. This approach is recommend to simplify sharing your scripts with others.

Readme

This text document has a brief description of each table at the root level, sort of like what you are reading now.

Scratchpad

This table is intended as a somewhat temporary storage area, although like all Frontier table entries, it is saved to disk and remembered from session to session. You'll probably find frequent use for the scratchpad table, particularly during development and testing of reasonably complex Frontier scripts and suites. We use this location in some of the example scripts in the documentation as well.

Suites

Suites are collections of related UserTalk scripts and data, usually attached to one or more private menus. See Chapter 10 for details.

System

The system table is one of the most important sub-tables in Frontier. As you can see from Figure 5-1, it includes a number of useful-sounding entries. Desktop scripts run from system.deskscripts. All of the verbs in UserTalk are defined in system.verbs and its many sub-tables. If you peruse this sub-table, particularly the sub-table called builtins, you may be surprised to find that a great many UserTalk verbs are defined in scripts that use other verbs in the language. Whenever you see a reference to the "kernel," you are looking at a direct call to the Frontier program.