Okay, by now you should know how to get around Frontier's database, and where to go.
But how do we refer to locations in the database in our scripts and macros?
Addresses
We refer to a location in the ODB by addresses. Addresses depict the path from the root to the object.
It's pretty simple really. My initials are in a string object called initials, in the prefs subtable of the user table of the root. So I'd refer to them this way: user.prefs.initials.
You can also type root.user.prefs.initials, but the root is always assumed, so it's not necessary. If you use the Jump dialog box (Cmd-J) [Ctrl-J], and type user.prefs.initials, you'll "jump" straight to that location.
Shortcut Paths
Now, if you work with Frontier just a little bit, you'll realize that we use lots of addresses that can't be traced directly to the root table. One example is Frontier's built-in macros. They are kept at html.data.standardmacros. But if you look at the root table, there's no root.html! Where are these macros then?
Actually, they are buried in the system table, at system.verbs.builtins.html.data.standardmacros. But it's not necessary for you keep track of that. Frontier keeps track of special places in the root--and checks them when it can't find an address at the top level of the root. This saves a lot of tedious typing!
For the most part, you don't need to worry about this. Frontier will find addresses for you, so if you see an address that you can't find from the root, just use the Jump dialog or hold down (Cmd) [Ctrl] and double-click on the address, and Frontier will open it for you. Okay, let's roll on--skip ahead to the next bold section.
For those of you who really want to know, the list of special places in the root is kept at system.paths. Don't modify this table! It'll make your scripts act in an unexpected manner, can corrupt the database, and may cause scripts or macros you write to be incompatible with the standard distribution of Frontier.
Address Names
Since Frontier uses the period to delimit database paths, periods are illegal in object names. Here are some other rules and conventions that will help you in naming your objects.
1. object names can contain both letters and numbers, but should begin with an alphabetic character. The underscore '_' is also valid. Other punctuation is not.
| Valid |
Invalid |
workspace.five
|
workspace.5
|
workspace.abc123
|
workspace.123abc
|
workspace.my_name
|
workspace.my name
|
2. However, if invalid characters are used in an object's name, it's still possible to refer to that object. Use braces and quotes to get this to work.
For example, an object in the workspace table called "My Funny Valentine" can be referenced like this (the spaces are invalid):
workspace.["My Funny Valentine"]
We commonly use the '#' hash mark to begin names of objects the website tables. The hash denotes directives or other special information used to render the page.
The Jump dialog has a shortcut that allows you to jump to a location that begins with a '#' hash mark without using the braces and quotes. Note that this is for the jump dialog only, and when referring to that object in a script, you should always use the braces and quotes.
Outside of the use of the '#' hash mark to denote directives, the use of invalid address characters is generally discouraged, as it causes more problems than it rewards in convenience.
We're almost done! Onward to our last stop, Caring for your database.
Page 1: Frontier's Database Defined
Page 2: The Advantages of Frontier's Database
Page 3: What's in the root?
Page 4: Navigating the Root
Page 5: Where do I keep my stuff?
Page 6: Database Names and Addresses
Page 7: Database Care and Feeding
Page 8: Object Database Tech Notes