Citrus: a Language and Toolkit for Simplifying the Creation of Structured Editors for Code and Data

Citrus: A Language and Toolkit for Simplifying the Creation of Structured Editors for Code and Data Andrew J. Ko and Brad A. Myers Human Computer Interaction Institute Carnegie Mellon University Pittsburgh, PA 15213 [email protected], [email protected] ABSTRACT Direct-manipulation editors for structured data are increasingly common. While such editors can greatly simplify the creation of structured data, there are few tools to simplify the creation of the editors themselves. This paper presents Citrus, a new programming language and user interface toolkit designed for this purpose. Citrus offers language-level support for constraints, restrictions and change notifications on primitive and aggregate data, Figure 1. To-do list and address editors created with mechanisms for automatically creating, removing, and the Citrus language and toolkit. reusing views as data changes, a library of widgets, layouts and behaviors for defining interactive views, and two user interface toolkit designed to simplify the creation of comprehensive interactive editors as an interface to the editors for structured data and code. Citrus distills what language and toolkit itself. Together, these features support have traditionally been toolkit-level features into first-class the creation of editors for a large class of data and code. language features, and offers toolkit-level support for features that have previously had to be implemented from ACM Classification Keywords: H.5.2. [Information scratch. The result is a simple, expressive and powerful interfaces and presentation]: User Interfaces—toolkits. language and accompanying user interface toolkit that is General Terms: Human Factors, Languages specifically designed for creating model-view-controller- Keywords: Structured editing, interface builder, toolkit. based direct-manipulation editors for highly structured data. In addition to including well-known features such as INTRODUCTION With the advent of XML, developers are creating a growing constraints and change notifications, Citrus includes number of graphical editors for structured data, including language-level support for restrictions on primitive and HTML editors, forms-based interfaces, visual programming aggregate data and for automatically synchronizing models environments, editors for source code, diagram editors, and and views as data changes. It offers toolkit-level support for even calendars, as well as editors for specialized data types drag and drop interactions and provides auto-completion to designed for particular needs. While many toolkits [1, 10, text fields with little to no additional code. Using these 14, 18] exist that can be used to create these editors, several features and others, the Citrus language can describe a wide common implementation tasks involved in building these range of data types, from simple data such as addresses, to editors, such as expressing constraints, validating user complex executable programs, as well as aid in the creation input, responding to changes of the data, and synchronizing of interactive editors for these data types. Citrus can even the models and views, are still cumbersome and error prone be used as an alternative to parser-generators such as in many circumstances. YACC by simplifying the creation of graphical structured editors for programming languages that will parse the In this paper we describe Citrus (Creating Interactive Tools resulting code as a programmer types. for Reshaping and Utilizing Structure), a new language and In the next section we offer an example of building the to- Permission to make digital or hard copies of all or part of this work for do list editor seen in Figure 1. We then describe the personal or classroom use is granted without fee provided that copies features of the Citrus language and user interface toolkit in are not made or distributed for profit or commercial advantage and that detail, followed by several examples of larger editors built copies bear this notice and the full citation on the first page. To copy with Citrus, including Citrus’s own specification editor and otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. interface builder, a flow chart editor, and a prototype of a UIST'05, October 23–26, 2005, Seattle, Washington, USA. Java programming environment. We end with a discussion Copyright 2005 ACM 1-1-59593-023-X/05/0010...$5.00. of related work and some brief conclusions. Copyright 2005 ACM 1-58113-957-8/04/0010...$5.00. Figure 2. The Citrus specification editor (left) and interface builder (right), used to create Citrus editors. CREATING A TO-DO LIST To arrange the checkbox and the text field, we type the Creating a Citrus editor involves writing a specification of expression (a HorizontalLayout spacing=10.0) for the the classes of data to be edited and then designing views for layout property at (d). By default, the top and left each class. As an alternative to using Citrus’s textual syntax properties of all views are constrained to the result of the and parser, Citrus also provides a graphical editor for each getLeft and getTop methods of their parent’s layout. We step, as seen in Figure 2. All of the code for creating an then type expressions for width and height at (e), fitting editor can be specified interactively using these tools. the view to its layout. The <- indicates that these properties are constrained, rather than initialized to these expressions. As our example, we will create the to-do list editor seen in Figure 1. We begin by defining the model, creating three To hide completed items in the editor, we write a constraint classes by dragging New Class from the toolbar at (a) in on the scale property at (f) that uses the done property Figure 2. We name them ToDoItem, ToDoList, and defined in ToDoDoc. It returns 0.0 if the done property of ToDoDoc. Each is declared with the syntax “a Name is a the ToDoItem and hide property of the ToDoDoc that Superclass,” followed by a list of declarations of the “owns” the ToDoItem are both true, and 1.0 otherwise. instance variables, which Citrus calls properties, of the To enable the insertion and removal of ToDoItems, we add form “Type name=expression restricted to [...].” behaviors to the view class by dragging them into the For example, ToDoItems have two properties, which we behavior panel at (g). When a carriage return is typed, a dragged from the toolbar: done, a Boolean, and whatToDo, a new ToDoItem will be inserted after the ToDoItem that the text string that has the regular expression value restriction view represents; when a backspace is typed, the ToDoItem at (b), disallowing carriage returns. In Citrus syntax, []’s that the view represents will be removed; and when a tab is denote list creation, ()’s denote method calls and typed, the ToDoItem will be replaced with a ToDoList. instantiations, and <>’s denote type arguments for generic classes (where List<ToDoItem> is a list of ToDoItems). A The views for ToDoList and ToDoDoc, shown at (h) and (i), ‘.’ gets a property’s value and @ gets a property itself. each have a placeholder that translates a property into an appropriate view for the property’s type. In this case, Next, we design views for the three classes, using the Citrus items, a List, is translated into a ListView, which updates interface builder on the right in Figure 2. Rather than itself as its list changes; list, of type ToDoList, is creating static displays like conventional builders, Citrus translated into an instance of the ToDoListView class that defines a view class that is instantiated for each instance of we defined. The “Save” button calls write on the ToDoDoc, data of a particular type. We define a view by choosing which uses a built-in routine to serialize the data in a views for each of a class’s properties. For example, for straightforward XML format. ToDoItemView, shown in Figure 2, we drag a checkbox and text field from the toolbar at (c). As we do so, the interface Building this editor with a more traditional toolkit would builder chooses an unused property in ToDoItem of the have required several lines of code to synchronize models appropriate type. These can be changed, if necessary, in the and views, to generate new views as items are inserted, to “Children” panel, which shows the children that will be validate whatToDo, to save the data, and to implement instantiated for each instance of ToDoItemView. constraints. Citrus manages all of these automatically. OVERVIEW Each property declaration has a value expression, which is We have built several powerful applications using the must be supplied as either an initial value (using the Citrus language and user interface toolkit, including symbol =), a constraint (using the symbol <-), or as a Citrus’s own specification editor and interface. The key to parameterized value that must be passed during Citrus’s power and simplicity lies in its language and instantiation (using the symbol ?). Value expression can be toolkit-level support for implementation tasks that typically overridden in instantiation expressions using the property’s must be done manually in other toolkits. In the following name. For example, the expression (a ToDoItem sections we describe this support in detail. done=true whatToDo<-“work”) creates a new ToDoItem, THE CITRUS SPECIFICATION LANGUAGE overriding the done property’s initial value with true, and Citrus is an object-oriented, statically-typed and interpreted constraining whatToDo to the text string “work.” This language, with support for generic classes and reflection. avoids the need to subclass when the only changes to an Like other object-oriented languages, Citrus programs instance are to initial values and constraints. Constraints on consist of classes that declare a list of named instance properties can also be set at runtime. variables and methods.

Load more