High-level Communication: Semantic Events

The low-level protocols open document manifestation and interaction with the user. They do not address higher-level logical or semantic actions, such as opening documents and sorting tables, but the spirit of the system demands that, no less than low-level actions, these high-level actions must be open to modification by any behavior.

As a high level action, semantic events are relatively infrequent and thus not performance critical. They are sent to all behaviors, with before and after phases. A semantic event consists of a message, such as openDocument, and three fields labeled argument, in, and out, whose exact content types depend on the message, though the rule of thumb is that argument corresponds to the most commonly needed auxiliary data, in holds the sender of the event, and out collects results from participating behaviors.

Semantic events are most often sent to request action and to announce state. Even when a behavior could directly invoke itself, it is often better to request the action and give other behaviors a chance to modify or cancel the request. Other semantic events announce potentially interesting state. Semantic events are most often acted upon by behaviors to implement a requested action, to modify the event, or to update state in response to an annoucement event.

For example, when a document has been loaded, surviving potential 404 File Not Found's and redirections, the system announces openedDocument (note past tense), and the forward/backward behavior adds it to history list. The search behavior announces its results in a searchHits semantic event, which is caught by the scrollbar visualization behavior. Media adaptors for HTML, directory listings, and Zip archive listings all send the table sort behavior, with sortTable as the message, and node and direction in fields. The table sorting behavior catches the event, inspects table to determine the data type of the requested column, sorts, and rearranges the document tree to reflect the sort order.

Example: TeX DVI.

TeX's DVI is a page description language like PostScript, but very simple: it has movement commands, registers, font changes, character drawing, and little else. Moreover, its author froze the format. Everything from hyperlinks to images to graphics drawing is implemented by means of "specials", which are embedded strings that are left to the viewer to interpret. There are probably hundreds of specials that have been defined, and different viewers implement different, usually small subsets. Supporting a new special involves hacking the source code, if the source code is available, and hoping the viewer's main author accepts the changes.

The Multivalent DVI media adaptor supports specials without modification of the parser-renderer with the same mechanism as used in the rest of the system, the behavior. The parser announces specials as semantic events, passing the special string, and geometric and logical (document tree) positions in fields. Behaviors implementing specials listen for the relevant messages, and have enough information in the fields to accomplish their work. The HyperTeX hypertext and PageSize specials are currently supported, and image and color will be.

Example: menu construction.

All behaviors have a chance to contribute to all menus, whether they drop down from the menu bar or pop up from document content, hyperlinks, or the selection. Menus are built on demand. At the moment the menubar behavior needs to build a menu, it sends a semantic event with message createWidget/menu-title, and seeds the out field with an empty menu. Arbitrary behaviors can add to the menu, and when the event returns to the menubar, the menubar formats and paints the resulting menu.

See Graphics User Interface.

Semantic Events in the Basic Browser

Some of the more important semantic events that are defined by built-in behaviors include the following. See Document.java, Browser.java, and others in API.

Conventions

fields named MSG_xxx