Layout Computation

The purpose of the LayoutComputation class is to implement the unparsing schema and to

arrange for associations between increments and portions of text or graphics. As dierent tools may have dierent unparsing schemas, this class is tool-dependent and cannot become part of the reuse library for tool construction.

Due to the need to re-compute the layout incrementally, dierent increment types have to be used as starting points. The dierent increment types depend on the supported language and, therefore, dier from tool to tool. On the other hand, the ToolKernelsubsystem should not

be aware of the dierent kinds of increments that can occur in a document in order to reuse the subsystem between dierent tools. The object-oriented paradigm is used to solve this dilemma as follows. UnparseIncrementhas an argument which determines the increment to be

redisplayed. The type of this argument is the class Incrementexported by theToolAPI. As we

will see later, any tool-specic increment class dened in the tool's schema inherits from this class. Exploiting polymorphism, arbitrary increments may, therefore, be passed as arguments to theunparseIncrementoperation. Therefore, the signature of theunparseIncrementoperation

remains stable between dierent tools. Furthermore, for each type of increment that can occur in the respective language, the class includes a hidden operation that implements the unparsing scheme for this type of increment. These hidden layout computation operations are invoked by

unparseIncrement. Which particular operation is invoked by unparseIncrementis determined

during run-time by the type of increment passed as argument.

The hidden operations that are used to compute the textual or graphical representation of an increment insert segments into the edit window. A segment is an atomic portion of text or a bitmap. To insert text or graphics into the window, the LayoutComputationclass needs a

reference to the EditWindow which is passed as an argument to the object constructor. The

operations, therefore, use an operationInsertIncrementPartprovided by class EditWindowand

pass the text as an argument. To insert the textual representation of a child increment, they call the respective layout computation operation available for this type of child increment. Figure 5.3 indicates the segments for the function displayed in an edit window of the Groupie module interface editor on Page 14.

\n \n FUNCTION ( IN p : ( IN TWindow;\n : TPosition ; upper_left IN lower_right: TPosition;\n IN name:STRING TWindow;

\n \n

: CreateWindow

/* creates a new window */

Figure 5.3: Segments of Text in an Edit Window

The LayoutComputation class for this tool contains an operation unparseFunction that rst

inserts a segment containing the keyword FUNCTIONand then a blank segment. After that, an

operationunparseOpNameis called. As argument to that operation, the increment identier of

the operation name is passed, which, in turn, is obtained from a traversal function exported by theToolAPIsubsystem. UnparseOpNamethen inserts the value of the function identier as a

new segment into the window and returns. UnparseFunctionthen continues inserting a blank

segment, callsunparseParameterListand so on.

In order to allow the user interface subsystem to associate segments with increments, the operation InsertIncrementPart has an additional parameter where the layout computation

operations pass increment identiers, which they obtain from the ToolAPI subsystem during

traversal. Hence, the rst two segments in Figure 5.3 are associated with the function incre- ment, the third segment is associated with the operation name increment, the fth segment is associated with the parameter list and so on. If the user then clicks on a segment, e.g. the rst segment containingFUNCTION, theUIMSpasses the function increment identier to the call-back

operation in theControlclass which uses this information to call the select operation exported

by the EditorManagerclass.

As required in Subsection 2.2.1, editors have to visualise inter-document consistency con- straint violations and static semantic errors. This visualisation can best be implemented in the LayoutComputation class. Before inserting a segment into the edit window, the layout

computation operations check whether the corresponding increment is error free. They do so using the operation has error, which is dened in the underlying database schema in the

most general class Increment and is thus available for arbitrary increments. The operation InsertIncrementParthas another parameter which determines whether the new segment is to

be marked or not. To implement the visualisation of errors, the layout computation operations only pass the result of the call tohas error as an argument toInsertIncrementPart and the

implementation of InsertIncrementPartin classEditWindowmarks the segment or not.

The class LayoutComputation has to access a number of operations from the schema. It,

therefore, imports operations from the ToolAPI subsystem. The operations include traversal

operations for navigating through the abstract syntax graph stored in the ODBS. Furthermore,

has erroris imported from a class exported by ToolAPI. In addition, the LayoutComputation

class intensively uses the InsertIncrementPart operation, exported by the EditWindow class