The Spreadsheet is a prime example of an end-user programming environment. The
“developer” enters his programs (formulas) directly in table cells, so the “programming”
is concrete and direct, and immediate feedback is provided.
Query by example (QBE)[21] formulas from the database world are similar. The
designer/user enters query expressions directly in table cells, and the system
automatically displays the rows that fit the expressions. In this way, the designer is
shielded from the complexities of SQL and programming syntax in general.
Both spreadsheets and QBE systems are examples of programming in the interface
systems, i.e., system in which the development interface and the target interface are the
same. Applications with macro-recording facilities are also of this type, as are
programming by example (PBE)[6,11] systems like SmallStar[9] Eager[5] and
Mondrian[12]. These systems are powerful because the developer “programs” using the
same operations and same interfaces that he is already familiar with as an end-user.
Programming in the WYSIWYG interface tools are slightly different. Here, the
development interface is not the target run-time interface, but a facsimile of it. The
developer still gains some benefit from visualizing the development interface as the target
interface, but he must mentally map the operations he performs during development to
the actual operations that will occur at run-time. These tools are freer than in the interface
tools, in a sense, as they can provide guides and even dialogs that help the developer
specify the program. Of course the more guides and helper dialogs, the less WYSIWYG
the interface is.
Interactive development environments like Visual Basic are programming in the
WYSIWYG tools, but for the most part they only provide visual methods of designing
the static layout of an interface. Specifying the dynamic parts of a program, e.g., what
occurs when a button is clicked, requires coding.
Note that the mapping is not from visual table to database table, but from visual table
column to database table column. Thus, one visual table can be mapped to multiple
databases, and one database table can be viewed in multiple tables.
In terms of existing commercial systems, our approach is most similar to that used in
Macromedia's Ultradev 4[]. Whereas Ultradev 4 a some programming in the WYSIWYG
interface
The goal of our research is to explore techniques by which a savvy computer user
(designer) can create complete dynamic web pages, without the aid of a programmer. Our
approach is to super-charge a WYSIWYG HTML editor with spreadsheet, Query By
Example (QBE), and Programming by Example (PBE) functionality, then provide a code
generation operation that creates an HTML page and a Java servlet. We call this approach
programming in the WYSIWYG interface, and we have developed a prototype,
WebSheets, based on the approach.
Macromedia's Ultradev 4 [14] (a combination of Dreamweaver and Cold Fusion) is as
close to an existing programming in the WYSIWYG system as there is. It does allow the
dynamic content of some programs that view and manipulate databases to be specified
without writing code.
But Ultradev 4’s process requires the designer to think in terms of a program; it is
only partially programming in the WYSIWYG. Many elements of the page must be
specified in dialogs outside the WYSIWYG interface, and the designer must understand
programming concepts such as parameters and result sets. In this sense, Ultradev 4 is
more of a visual interface to a program, as opposed to a programming in the WYSIWYG
tool.
Websheets, on the otherhand, allows a dynamic web page to be designed directly in the
context of the WYSIWYG interface. With WebSheets, the designer first maps a visual tables to a
database table, either using a dialog or by asking the system to generate a database table from a
sample row. After this mapping, special rows appear in the visual table that guide the designer in
specifying database operations (see Figure 1). The sample row allows the designer to specify the
formatting of the data to be displayed. The other rows allow the designer to specify the database
records that should appear (selection) the database operations (add, delete) that should occur, and
the computations that should be executed on the data.
When the designer enters QBE and spreadsheet formulas in cells, he is not specifying
them for the sample data that appears at development time, as with a spreadsheet. Instead,
the expressions entered in the WYSIWYG table map to run-time operations that access
and manipulate the underlying database table, and, in some cases, manipulate the runtime view of that table.
At any time during development, the designer can ask WebSheets to generate code
and run the program. The system generates servlets, automatically registers them with a
server, and runs the new dynamic pages in a browser.
An HTML template file and a Java servlet is generated. The template file is sent to the
Lutris XMLC compiler, which generates a Document Object Model (DOM) tree
representation. The generated servlet manipulates that DOM tree to add the dynamic
content.
during development. WebSheets allows a user to directly map input parameters to output
table cells, as shown by the dotted arrow from the MinStock text of Page1 to the
reference in the DelSelect row of the table in Page2.With servlet programming and
approaches such as that of UltraDev 4, the mapping is not so direct, as shown by the
series of darkened arrows.