Presentation Types in CLIM

Abridged Notes Chapter 8 of Franz CLIM User Guide

The below are abridged, very lightly modified, notes from Chapter 8 Presentation Types in Franz’s CLIM 2.2 User Guide. All credit and copyright belong to Franz and their documentation represents an excellent example of technical writing, for which I’m highly grateful for.

In object-oriented programming systems, applications are built around internal objects that model something in the real world. For example, an application that models a university has objects representing students, professors, and courses.

Users need to interact with the application objects. In most user interface systems, the interface is constructed in terms of the objects in the UI toolkit; these objects must be converted, by the programmer, into the objects of the application. For example, choosing one of a set of objects might require you to build a radio box that has in it a set of buttons. Each of these buttons stands for one of the objects being chosen among. You must also write code that converts each of these buttons back into an application object, so that when the end-user picks on of the buttons, the correct application object is chosen.

If you later decide that the radio box is too cumbersome (perhaps because there are many selections in it), and you wish to change the user interface to use a list pane or option pane, you must then rewrite all of this code to use the new toolkit objects for list or option panes.

A CLIM user interface enables users to see a visual representation of the application objects, and to operate on them. The objects that appear on the screen are not the application objects themselves; they are objects called presentations that are one step removed. The visual representation of an object is a stand-in for the application object itself, in the same sense that the word ‘cat’ (or a picture of a cat) is a stand-in for a real cat.

In CLIM, the user interface is constructed is terms of the application objects, and CLIM worries about the toolkit objects. Taking the same example, all you need to do is to specify that you wish to select one of the application objects by using the member type. CLIM deduces that this can be done via a radio box, and creates the radio box for you. If you later decide to use a list pane or option pane, you can advise CLIM to do this by explicitly specifying a view. At no time do you need to worry about the toolkit objects.

The most basic part of designing a CLIM user interface is to specify how users will interact with the application objects. There are two directions of interaction: you must present application objects to the user as output, and you must accept input from the user that indicates operations on the application objects. This is done with two basic functions, present and accept, and some related functions.

8.1.1 Presentations

CLIM keeps track of the association between a visual representation of an object and the object itself. CLIM maintains this association in a data structure called a presentation. A presentation embodies three things:

• The underlying application object
• Its presentation type
• Its visual representation

8.1.2 Output with its semantics attached

For example, a university application has a ‘student’ application object. The user sees a visual representa- tion of a student, which might be a textual representation, or a graphical representation (such as a form with name, address, student id number), or even an image of the face of the student. The presentation type of the student is ‘student’; that is, the semantic type of the object that appears on the screen is ‘student’. Since the type of a displayed object is known, CLIM knows which operations are appropriate to perform on the dis- played object, irrespective of what visual representation is being used for the object. For example, when a student is displayed, it is possible to perform operations such as ‘send tuition bill’ or ‘show transcript’.

8.1.3 Input context

Presentations are the basis of many of the higher-level application-building tools, which use accept to get input and present to do output. A command that takes arguments as input states the presentation type of each argument.

This sets up an input context, in which presentations of that type are sensitive (they are highlighted when the pointer passes over them). When the user gives the ‘send tuition bill’ command, the input context is looking for a student, so any displayed students are sensitive. Presentations that have been output in previous user interactions retain their semantics. In other words, CLIM has recorded the fact that a student has been displayed, and has saved this information so that whenever the input context expects a stu- dent, all displayed students are sensitive.

8.1.4 Inheritance

CLIM presentation types can be designed to use inheritance, just as CLOS classes do. For example, a university might need to model night student, which is a subclass of student. When the input context is looking for a student, night students are sensitive because they are represented as a subtype of student.

8.1.5 Presentation translators

You can define presentation translators to make the user interface of your application more flexible. For example, suppose the input context is expecting a command. Since CLIM commands are first class appli- cation objects, in this input context, all displayed commands are sensitive, so the user can point to one to execute it. However, suppose the user points to another kind of displayed object, such as a student. In the absence of a presentation translator, the student is not sensitive because the user must enter a command and cannot enter anything else to this input context.

In the presence of a presentation translator that translates from students to commands, however, the stu- dent would be sensitive. In one scenario, the student is highlighted, and the middle pointer button does ‘show transcript’ of the student.

8.1.6 What the application programmer does

By the time you get to the point of designing the user interface, you have probably designed the rest of the application and know what the application objects are. At this point, you need to do the following:

• First decide which types of application objects will be presented to the user as output and accepted from the user as input. For each type of application object that the user will see, assign a corresponding presentation type. You will need to define accept and present methods for these objects, unless these methods can be inherited from a superclass. In many cases, this means simply using a predefined presentation type. In other cases, you need to define a new presentation type. Usually the presentation type is the same as the class of the application object.
• Decide which of the application’s operations should be available from the user interface, and define commands for each of these operations. These commands can be made available from a variety of interfaces (such as menus or dialogs, command lines, and so on). This is a detail that can be decided as you continue to develop the program.
• Use the application-building tools to specify the windows, menus, commands, and other elements of the user interface. Most of these elements will use the presentation types of your objects.