An Object-Oriented Scripting Environment for the WEBSS Electronic ...

5 downloads 38 Views 871KB Size Report
Nov 30, 1992 - This paper presents the scripting facilities built on top of WEBSS, an interactive system for the creation and consultation of electronic books.
MILANO,

NOVEMBER

30-

DECEMBER

81

4, 1992

An Object-Oriented

Scripting

for the WEBSS

Electronic

Environment Book

J. Monnard, J. Pasquier-Boltuck Institute for Automatwn and Operations Research, University

System of Fribourg

CH-1700 Fribourg, Switzerland monnardj@@ni51 .bitnet, pasqu”[email protected]

Abstract

This is no longer the case with current systems. Users can now manipulate

This paper presents the scripting

facilities

built

on

top of WEBSS, an interactive system for the creation and consultation of electronic books. The sclipting environment relies on the same object-oriented software architecture used in the design of the WEBSs application, rendering it consistently integratcxi with the other components of the system. Scripts enhance the application in two ways. First, the ability to combine basic WEBSS actions allows users to easily define new high-level functions like, for example, the automatic creation of tables of contents and indexes. Secondly, the behavior of the objects that constitute an electronic book can be enriched by writing scripts that will be automatically executed each time a triggering object performs a specific action. The main originality of our scripting model resides in the fact that a script maybe attached not only to an individual object, but also to all

new kinds of documents,

active

ones that include dynamic information (video, music), perform actions and behave differently according to the needs and wishes of users. One solution for providing these advanced capabilities is to write scripts – small programs specifying the actions to accomplish – and attach them to the documents. Experience with systems offering scripting facilities, like NoteCards [2], Scripted Documents [13], or the Andrew ToolKit [9, 3], has shown that this approach presents a considerable potential for enhancing the functionality of hypertext. Another promising direction that hypertext research has been exploring

for some years is object-

oriented programming (see e.g. Intermedia [4]). This approach applies particularly well to hypertext because it is very easy to find a correspondence between its elements (documents,

blocks, links) and

objects of a specific class, or to all objects in a certain set.

object classes, which are a key concept of the objectoriented paradigm. The system described in this paper, WEBSS

1

(Woven Electronic Book System with scripts), combines the scripting and object-oriented approaches in an original way. In designing our scripting

Introduction

The information manipulated by hypertext systems has undergone a remarkable evolution in recent years, The first systems linked elements that were rather passive - they contained mainly static data (text and graphics) and did not react or change interaction.

Permission is granted

to copy provided

without that

fee all or part

copies

upon user

ma,terial

or distri

but ed

for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission c~f the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. @1992

ACM

O-89791-547-X/92/0011

/OOSl/

application, interfering

one that could be easily used without with the basic behavior of the system.

Secondly, our solution should enable users to enhance the application at a high level of abstraction. And finally, the scripting component had to be

of this

are not made

concept, we had three main goals. First, we wanted to provide a lightweight way of extending the

$1.50

consistently integrated within the system. To reach these objectives, we implemented a system that combines two important characteristics: “

The scripting

facilities

rely on the same object-

oriented software archit~ture the application. ●

used in the design of

Scripts can be attached to individual

objects, to all

82

ACM

objects in a certain specific class.

set, or to all objects

ECHT

CONFERENCE

blocks and links called webs. This information space may also be hierarchically structured with the help of

of a

To further explain scripts: Section 2 gives an overview of WEBSS and briefly describes its software

specialized documents called browsers, Documents. Textual and graphical

architecture. Section 3 exposes the key ideas of our scripting concept, along with a few examples. The syntax of scripts is presented in Section 4, highlighting interesting features of the scripting language. Section 5 sketches the main components of

available, as well as browsers and logicomathematical models (e.g. Markov chains or linear programming models). Each class of documents

draws some conclusions and gives direction of further

anyone, or to a reader, in which case it is private. Blocks and links. A block represents any selection

research.

Overview

2.1

are

includes the relevant group of methods, which allow it to manipulate its data (e.g. formatting for a text document or computing for a model). Every document belongs either to the author of the IEB, in which case it is considered public and may be consulted by

the scripting environment. Section 6 describes our first experiences with scripts. Finally, Section 7

2

documents

made inside a document (e.g. a string of characters in

of WEBSS

Basic

a textual document). The connection between two blocks is created by a link, which the user may

Elements

choose to follow in order to jump from one location in a document to another (or even to another document). Browsers. A browser is a tree-structured document, each node having one or more associated documents. Browsers are used to hierarchically organize subsets of

WEBSS [7] is a hypermedia environment for the creation and consultation of Integrated Electronic Books (IEB). An IEB represents an organized gathering of knowledge on a given subject. It consists of a collection of documents that can be interconnected with the help of semantic nets of

documents. Different

Gmphe - Wernple

?.

\l.

Efbmma h tibuh

II

z. I Cluaificati,,

I

I

2

Enoncb- Enemple2

,k

-“”’=1 (MT=4M’

operations may be applied to the

Dans w Immeublo, on a Instatlb w ghbrateur pour pal)iw 1.s coupur.. cf9 courent Uhe InterruptIon se pmduit en mqpme tow les trots roots et dure en mqyntw we Joutie. Ce groups 61ecWogW pwt wok das wnnes Iarsqult 9.1.. ott.nt.. S$.na penns survl.nt, {! n. wut alors P.* entrer m service en cas de cowwo de

‘2?11mumntLimmub1 IL ‘ ‘ I “’NA2-JW ~p.z

fm”.ts

40s$1.*S

**..*.”,*

“1

-..M



)-i

l.b$

w>”’ L “

~

~

.ta!

~

‘-

I



Ax

WI

I

d’blwtr!.ttb E“ ‘stand b“-, UIU P..”. survlcnt WI mogentn uns fots WwsW !5 In.ats.

3 ~

I

1~’

Mwkou

- Cnemple

2

Fonct. de lfablliM

O.fo

,

:“--” am

- Liamplm

2

--

0.70. Om. 0.s0. 0.40. Om.

I

I

I

Figure 1: A screen shot from a WEBSS session with an IEB on Markov chains. By clicking on node “4.2 Le g6n6rateur” in the browser on the left, the user has opened a group of four documents that present an example. The up~r two documents contain graphical and textual descriptions of the example. The lower two documents contain the corresponding executable Markov model, and a reliability function that was computed by selecting an item from the Calculate menu. All these documents are interconnected by links, that can be followed by doubleclicking

their markers (o),

MILANO,

NOVEMBER

30-

DECEMBER

83

4, 1992

Figure 2: The software architecture of WEBSs

documents associated to a browse~ sequential opening (cf. NoteCards Guided Tours [12]), printing, searching for a word, etc. Sets. Another construct available in WEBSS is the set, which represents a collection of (pctssibly heterogeneous) objects – documents, blocks, links, scripts or other sets. Section 3 depicts the important role played by sets in scripts.

which encapsulates the functions generic Macintosh applibtion. ●

needed by a

The WEBSS general layer supports the “electronic book” capabilities, including the management documents, blocks, links, sets and webs.



The WEBSS

models

layer

contains

of

a specific

corpus of classes and subclasses for each type of documents supported by WEBSS.

2.2

Domains

of

Application

This

WEBSS is a general hypertext system that can be applied in various domains. Our research, however, concentrates on electronic books. The originality of WEBSS resides in the possibility of creating documents associated with logico-mathematical models that serve to perform complex manipulations and computations. WEBS (without scripting facilities) was effectively used to create electronic books on selected chapters of Pascal Programming and Operations Research courses taught nt our institute (Figure 1). 2.3

Software

Since WEBSS’ software architecture served as the basis in designing the scripting facilities, it is useful to have a minimal understanding of it. WEBSS was implemented in Object Pascal with the MacApp library of classes, and relies on an object-oriented software architecture: all the elements manipulated by the application (documents, !$ocks, links, sets) are objects that belong to specific classes. Fig,ure 2 shows the three distinct layers of such classes: ●

The MacApp

layer is an extensible

framework

design

is well-suited

for the

facility. First; it of the application

capabilities, which are supplied mainly by the objects and their encapsulated behavior and are accessed through the protocol defined by each class. Thus, scripts can easily duplicate application functionality by using the same protocol. Secondly, objects represent natural targets to which scripts may be attached. Finally, the execution model of our scripts makes use of two key elements of object-oriented programming, 3

Architecture

object-oriented

implementation of a scripting provides a high level definition

3.1

Key

i.e. classes and methods.

Ideas

Rationale

of Scripts behind

Scripts

Upon experimenting with the previous version of WEBSS (without scripts), we systematically analyzed the comments of users [8]. We found the system to have two main shortcoming~ (1) it didn’t provide enough support in the authoring process of an electronic book (the creation of many links and browsers is complex and at times a monotonous task); (2) users had no way to adapt the application to their needs (except for trained Object Pascal

ACM

84

programmers

with

a good knowledge

we mean by lightweight

of MacApp).

Theneed foractive, eras Meyrowitz [5] calls them, “responsive” documents that respond to user demands by executing actions was the third rationale that led us to include scripting facilities in WEBSS.

What

3.2

is

a Script?

In its simplest form, a script is a list of commands which are executed automatically as if they had been entered one by one by the user. Scripts

may also

ECHT

CONFERENCE

extension of the application.

For instance, the standard behavior when following a link is to show the link endpoint. But a script can be written such that following a link displays a message on the screen before going to the endpoint. Attaching a script to a block also permits the definition of virtual links, whose endpoints are calculated at execution time. There are, however, approach

that allows

two

difficulties

with

an

scripts to be attached only to

such as loops and

single objects. First, a consistent behavior of the system cannot always be guaranteed with a multitude

conditionals, as well as calls to predefine functions and other scripts. By giving users the possibility of automating and

of scripts disseminated among many individual objects, as in a system like HyperCard [1]. If the author of an electronic book is not cautious when

sequencing any series of actions, scripts allow for interaction with the application at a higher level of

assigning sc’tipts to objects, readers may become disconcerted because similar objects respond in different ways to the same command. Secondly, we should keep in mind that an IEB is a complex body of knowledge and consists of numerous objects. Some

include

sequencing

instructions

abstraction. A complex set of actions can be made an atomic objec~ which can then be played back at will in different contexts. By writing the appropriate script, a user can for example open all the documents that belong to a specific set with a single operation. Scripts have a great variety of applications in hypertext (see [13] and Appendix for examples). In WEBSS, they can be used to facilitate the authoring and reading processes of electronic books by automating the creation of structures. Scripts can for instance generate browsers by filtering and collecting

only

those

a set of documents that

meet

specific

conditions (e.g. all documents containing and whose name starts with “Example”),

pictures

create indexes by searching for all occurrences of specific words in a group of documents and creating links to a document where their meaning is explained.

form

of

coordination

between

Writing

Execution

Model

How can a script be launched? The first possibility quite obvious

a script can be invoked

directly

is

by a

user. In this sense, a scripting system represents a kind of high-level macro facility, a useful improvement already provided by many applications. But this, of course, is not the only option. WEBSS offers another way of launching a scripc a user can also decide that a script will be automatically executed each time a triggering action is performed by a particular object, like the opening of a document. This powerful mechanism enables the user to affect the way an object reacts to an action while at the same time preserving the standard behavior defined for this action by the object’s class. This is exactly what

is

highly

a script triggered by the Open action to verify

this condition is quite easy, but assigning a separate copy of this script to each document in the group is a tedious and error-prone task. The implication is clem influencing the behavior of individual objects is not sufficient. Users must be able to alter the behavior of objects collectively. The solution we propose with WEBSS is the following A script can be attached not only to an individual object, but also to all objects in a certain set, or to all objects of a specific class. This original feature remarkably

3.3

them

desirable. As an example, consider the following situation: an IEB contains a group of documents on a specific subject, which should be opened only after having read the introduction in another document.

increases the range of

applications for scripts because it requires minimal effort to obtain a common behavior

only a from a

group (set or class) of objects. In the example above, the user must merely

create a set containing

all the

desired documents and attach the script to it. Thereafter, when any document in this set is opened, the script is executed. Other scripts can: — add any document from class TextDocument to the set “Visited Text Documents” when it is opened. The set may later be used for miscellaneous Purposes (history, searching), — open all the documents in a given set with the same position on the screen to maintain a consistent window arrangement throughout an electronic book, facilitating its consultation. Such

MILANO,

NOVEMBER

30-

DECEMBER

4, 1992

85

L

TWEBSsObjeet

-t TWEBSsDocument

-i-

I

5 TBlri~

TModell)oeument

I

kklkl

TModelEUoek 1

Figure 3: The classes of objects that can be used in scripts. TModelDocument

and TModelBlock

stand for any

kind of document and its associated blocks. presentation rules are only one example of the use of scripts for making an electronic book “semiformal”. In this sense, WEBSS jies hallfway between unstructured hypertext and systems that rely on formal models (e.g. Petri-Nets in ~1’rellis [10], or conceptual documents [6]). With our multilevel objects

triggering

model, the behavior of

may be influenced

both

individually

and

WEBSS scripting facilities are aimed at the end user, they must access the same elements that were directly manipulated when consulting an IEB, i.e. documents, blocks, links and sets. All these objects are instances of WEBSS classes. In fact, the classes of objects that can be used in scripts (see Figure 3) represent a subset of WEBSS class hierarchy. Note that we included a TScript class, which means that scripts are first class

single object to activate several scripts, it allows for

objects and benefit of all the implied properties such as access rights or versioning. To ensure transparent

quite elaborate uses. An author can for instance create a library of public scripts that add generic functionality to the objects of an IEB. Readers can

object access in scripts and establish a stable semantic level of interaction between the users of the scripting facility and the application, the only task remaining is

collectively.

Combined

with

then reuse these scripts

the possibility

and supplement

for a

them by

attaching their own scripts to specific objects. If several scripts are triggered by the same object/action pair, they are all executed successively. The order of execution goes from general to specific scripts: scripts,

first

class-bound

and finally

scripts,

object-bound

case, it is the responsibility ensure that the different

then scripts.

set-bound In such a

of the script writers

scripts do not conflict.

to

They

are aided in this task by the system, which can display a list of all the scripts that may be triggered lby an object

and provides

an easy way of disabling

the

automatic execution of individual scripts (cf. Section 5). Furthermore, we are presently working on additions to WEBSS scripting environment that would help analyze all scripts/objects relations in an IIZB and let users specify, for each object, which scripts must be excxxted and in which order. 3.4

Objects

in

Scripts

One of the key issues in designing the scripting component was to decide which objects would be allowed in scripts. The answer was simple: since

that of defining a subset of the attributes and methods of each class that will be available in scripts. From a conceptual point of view, the scripting component can be compared to a filter which hides the underlying complexity of the application to the user while relying on the same software architecture. This design has several advantages. Obviously, meets the requirement consistently

integrated

it

that the scripting component be within

the system. Since our

execution model allows a single object to trigger several scripts, script writers can also make use of the inheritance mechanism to create scripts of varying specificity y (e.g. for the classes TWEBSsDocument and TTextDocument). The integration of new models into WEBSS is also facilitated: when a new class of documents is added to the system, it automatically inherits all the scripting capabilities available in generic WEBSS documents. At the same time, modelspecific functions can easily be included by supplying the desired access methods to scripts. Moreover, the triggering mechanism can be applied to any subclass of TWEBSsObject, provided it makes sense. Simple examples are the following of a link, the opening of a document, or the double-clicking of a block. But in a

ACM

86

less trivial case, one could also attach a script to the AddObject method of a particular set to ensure that it will not contain more than ten documents. Now having described the scripting model, two questions arise: How are the triggering method and objects specified? And what can scripts do? These are answered in the next section.

Syntax

4

A WEB% ●

and

Contents

the object(s)

to which

the

script is attached and the method that will trigger its execution, ●

a main

block

that

contains

declarations

typeName> electronic

specification.

of

Script

Every

book has a type attribute

be

object which

in

an

can take

any value from a user-defined lis4 enabling users to define their own categories of objects (e.g. the link

of

example, a script begiming with a header of the form “On Follow of any Link of type Reference” will only be activated by links of type Reference. 4. 1.3

Set-Bound

Syntax: Examplex

Format

with this type of header will

triggered by any object that belongs to the class (or a subclass of) objectCkzss. Interesting in this header is the optional in [setName] On Open of any TextDocument in llxampleDocuments]

A script header can have four different formats. The first three formats, used in triggered scripts, specify

This header means that any object from class (or a subclass of) objectClass that belongs to a set named

the triggering

sefName – with an optional

method

and whether

the script

is

attached to a single object, to all objects of a certain

activate the script.

class or to all objects in a certain set. The last format is reserved for unbound scripts, i.e. scripts that are not

4. 1.4

attached to any object. Unbound scripts are either activated directly by the user or called by another script. 4. 1.1

Object-Bound

Syntax: Example:

of the script, objectClass

Class-Bound

On Execute cparameterLisD

Example

On Exwxm@eDoc:

Document):

and The optional indicate that the script accepts parameters and/or returns a result.

4.2

Main

Block

the

class (or superclass) of the triggering object, and objectName its name. Note that scripts are bound to object names and not to the objects themselves: a script can refer to a name even if no object with this name exists. This atlows users to write a script in advance if they know the name of the future object. When an object is later created with the name mentioned in the header, the script will automatically be applicable. 4. 1.2

Scripts

Syntax:

Scripts

On method of objectClass [objectName] On DoubleClick of GraphBlock munchAnimation]

the execution

– will

Integer

In this header, method specifies the method that will trigger

Unbound

type specification

Scripts

Syntax:

On method of any objectClass cof type

Example

typeName> On Follow of any Link

The main block contains declarations

of variables and

a list of statements to be executed. The syntax for statements is very similar to that of Object Pascal, including loops, conditions and assignments. The scripting language includes the types integer, string and boolean, as well as all the classes from Figure 3 (class names are simplified in scripts - e.g. Document - to facilitate is used instead of TWEBSsDocument the job for script writers and enhance legibility). Other characteristic elements of scripts are descrikd below (see also Appendix). ●

A construct

is provided

to perform

a group

of

statements on every object in a set. ●

Objects can invoke methods, using a dot notation.

MILANO,

NOVEMBER

30-

DECEMBER

87

4, 199z

The script browser, shown in Figure 4, is the main component of the scripting environment. This is where most script-related operations take place: creation, edition, syntax checking, etc. From the pop-

Calling of inherited methods is supported. objects attributes are also accessed through methods (e.g. there are SetName solution facilitates attributes, ●

Scripts

and GetName methods); this the definition of read-only

up menu on the top left,

may call predefine

example,

display

functions

scripts scripts

– to, for

a message or activate

a menu

their Execute method. In fact, unbound scripts, which cq take parameters and return a restd~ can



To

access

displayed in the right pane. The contents of the script selected from this list are displayed in the lower pane, where it can be edited. Commands for manipulating

global functions.

an object

by

name,

the

nc~tation

scripts and executing from a Script menu.

[objectName] is used. When the script is executed, the system searches among all the objects in the active IEB for an object with the name objectName and generates an error if none is found. Statements within a script may also refer to

.

This section

IEB,

.

.

and facilities

for viewing

.

.

.

name

.

.

that the script is enabled be executed

when

the

on the check

mark

toggles

its state,

allowing users to easily turn on/off individual scripts. A command also exists for globally disactivating the automatic execution of scripts. It is intended for users who want to consult an IEB without triggering any scripts. This command,

Environment

on the main elements

. . ..

automatically

Clicking

focuses

scripts are available

triggering conditions defined by its header are met.

of the

scripting environment that allow WEBSS users – whether script writers or simple end users - tc~work efficiently with scripts. They include a script br,owser, which provides rapid access to all the scripts in the active

.

A check mark indicates

and will

current.

of the Scripting

unbound

The symbols that appear next to a script have the following meanings:

the object that triggered the current execution with

5 Sketch

of

scripts, objects.

Depending on this choice, the left pane shows a list of classes, sets or object names. By choosing an item in this list, the corresponding list of scripts is

command – and other unbound scripts. Since scripts are objects, they are called by invoking

serve as userdefined

users select the kind

they want to visualize: unbound for classes, sets or individual

however, must be used with caution, because some important functionality may be disabled and the electronic book may not behave consistently.

and editing

A question

object properties and sets.

mark is displayed

if a script has not

been compiled or contains errors.

~ script Browser Classes Order: B Color Pictures

by Script Name

1

~ # d

Jacbw Blocks Links to Models $peciai Links 10 Pictures Uisited Documents

~ flepiaCeTeHt ~ Script X36

On Open of any TeWlownent tn Se OnCloseof any TeWOocumentin Se

.

on open of any document i n set [Exanp I e Documental; beg in I f not [Uislted Exosples]] ,ContainsObj ect(curpent)

then

[Uisited Exanples] ,llddObject(current) e I se i f Uset+lantstlessages then Ilessage(

‘you

are

apenlng

a dacument

gau alrwodg

Figure 4: The script browser. A list of scripts for the set “Example and script “CheckVisited2”

uisltedl

‘ );

Documents”

is displayed in the right pane,

is currently being edited. The arrow on the left indicates a syntax error.

ACM

88

~Public

wripm(crabytieautiorof

m~.)

indicated by a read-only icon. They cannot be modified by readers but can nonetheless be enabled

combined electronic

or disabled.

Figure 1:

Experiences

The scripting environment

with

one of the four sets GraphicDescriptions, TextDescriptions, MarkovModels and ReliabilityFunctions. He has also created four template documents. When a reader opens one of these documents, a set-bound script (see script #1 in Appendix) places it on the screen at the same position as the corresponding template document. Thus, if the author wants to change the

Scripts

disposition of the windows for all the examples, he needs just change the position of the templates.

described in this paper has

been implemented and is currently being tested*. The fwst user experiences are quite positive and show that

The class-bound script



Tmstl

by the

Class: ToutIfacum.ant

J

In: 13

Tgpst,

i,, Default Other... Create m: n, ec Contained

#2 (also triggered

Open action) puts each document in the set “Visited Documents”. When he is finished with

scripts are a real enhancement to WEBSS. We present

Name:

the different kinds of scripts to enrich the book on Markov Chains presented in

The author has put all the example documents into



object properties (name, type, etc.). This is accomplished by means of a dialog box (Figure 5) which can be invoked for any object in an IEB. Finally, WEBSS offers simple facilities for creating and editing sets (Figure 9.

Early

CONFERENCE

here an example that demonstrates how 8ssauthor has

are

Since scripts may be attached to objects, the system provides a way for users to visualize and modify

6

ECHT

,

91

11:25

in sets:

B~: aufhor Enabled

Uisited Oocuments Fred’s Oocuments Ewtmple Oocuments

scripts

lest Script Script *28 Steplacelwt Script #36

for this

objecti

1

rll ml Figure 5: A dialog box for viewing and editing object properties. Note the type attribute, which maybe selected from a pcsp,up menu. Also relevant for script writers are the two lists showing the sets to which the object belongs, as well as all the scripts that apply to it. / Set Name :

Ewmple

Oocuments Not in sat :

In set:

D(’

Suggest Documents