Download iui2000WebSheets - USF Computer Science

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

IMDb wikipedia , lookup

SQL wikipedia , lookup

Microsoft SQL Server wikipedia , lookup

Open Database Connectivity wikipedia , lookup

Concurrency control wikipedia , lookup

Entity–attribute–value model wikipedia , lookup

Database wikipedia , lookup

Ingres (database) wikipedia , lookup

Microsoft Jet Database Engine wikipedia , lookup

Extensible Storage Engine wikipedia , lookup

Clusterpoint wikipedia , lookup

Relational model wikipedia , lookup

Database model wikipedia , lookup

Transcript
Designing Dynamic Web Pages and Persistence in the
WYSIWYG Interface
David Wolber, Yingfeng Su, Yih Tsung Chiang,
Department of Computer Science, University of San Francisco
San Francisco, CA., USA.
wolber,suyi2,[email protected]
Abstract
WebSheets is a programming in the WYSIWYG interface
tool for building dynamic web pages that access and
modify databases. Without programming, designers can
specify not only the presentation of a page, but the dynamic
content as well. This capability is facilitated through a
novel application of Programming by Example (PBE),
Query by Example (QBE), and spreadsheet formulas within
the WYSIWYG HTML editor environment.
Keywords
PBE, QBE, Spreadsheets, HTML, dynamic web pages
INTRODUCTION
Plenty of visual tools exist for building static web pages,
but few allow dynamic web pages to be developed without
programming. Template frameworks like XMLC [3] help
by allowing designers to specify the presentation of
dynamic web pages in a WYSIWYG editor. Programming
is still required, however, to specify the dynamic content of
the page (that replaces the hotspots in the template).
UltraDev 4 [4], which combines Macromedia's
Dreamweaver technology with ColdFusion, is one
exception: a complete page can be built without
programming. But the system is more of a visual veneer on
top of a program: much of the specification is dialog based,
not direct manipulation, and it does not fully exploit wellknown end-user techniques long used in databases,
spreadsheets, and PBE[2] systems.
The objective of our research is to explore applying such
techniques to the WYSIWYG HTML environment, and
specifically, for the purpose of building dynamic pages that
access and modify databases. We have built a prototype
WebSheets, which allows most "programming" to occur in
the WYSIWYG interface, not a dialog, and which allows
the designer to work directly in the context of the target
interface, not an abstract program. The designer never need
enter an entire SQL or programming statement, or refer to
programming entities such as result sets or parameters.
Our experience watching the first users of the system
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise,
or republish, to post on servers or to redistribute to lists, requires prior
specific permission and/or a fee. IUI’02, January 13-16, 2002, San
Francisco, California, USA.
Copyright 2002 ACM 1-58113-459-2/02/0001…$5.00.
suggests that it can significantly reduce development time
for programmers, and it can allow for most nonprogrammers to create complete dynamic web pages.
DEVELOPMENT PROCESS
WebSheets provides the designer with the standard HTML
editing capabilities. Things get interesting, however, when
the designer inserts a table into the editor. At that point, the
designer can either map the visual table to an existing
database table using a dialog, or enter sample data for it
within the HTML table, and tell the system to create the
database table and mapping automatically (PBE). The
development-time HTML table then represents both a runtime visual component and the mapped database table. The
designer then specifies persistent data and operations using
the sample visual table. We call this process programming
persistence by example.
If the designer saves the program immediately after the
initial mapping, the resultant web page would display all
records of the mapped database table in the visual table.
Often, however, the designer desires more.
After the mapping, the development-time table appears
with one sample row of "live" database data, and three
other rows, one each corresponding to the SELECT, ADD,
and DELETE database operations (see Figure 1).
The designer formats the sample data by example in each
cell of the Sample Row. At run-time, the sample formatting
of each column is applied to all records (rows) that appear
(e.g., all titles in the table of Figure 1 will appear
italicized).
The designer enters QBE expressions in the View Select
row to specify the database rows that should be displayed.
The designer need not understand SQL syntax, as all
expressions are entered in the context of table cells. The
designer need not even name the column that the
expression is entered for as the column name is implied by
the location of the entered expression. For instance, if the
designer enters expressions in the View Select row as in
Figure 1, the system will build the query:
SELECT * from BookTable
where InStock>10 and Price>22.00
The generated servlet will invoke this query, this display
the results in the HTML table. The Delete Selection row is
similar to the view selection row, but the QBE entered is
used to choose which rows are deleted from the database,
not viewed. If “Kafka” were entered in the author column
To appear in the Intenational Conference on Intelligent User Interfaces (IUI 2002, San Francisco, CA).
But depending on what tab is selected, the three database
operation rows can show different formulas. Using the tabs
to differentiate various entries into the dynamic page, the
designer can specify how two pages communicate, or a
single page with multiple buttons and operations.
Figure 1. WebSheets Development of a BookStore
page.
of the Delete Select row in Figure 1, the following SQL
statement would be generated:
DELETE * from BookTable where Author=Kafka
The Add Row facilitates the creation of pages that allow the
end-user to enter new records in a table. If one enters
constant data in the add row, a record containing that
constant data is entered in the database table each time the
page is invoked. But the names of other components can
also be entered, as will be discussed shortly.
Input Forms
Unlike spreadsheets or DBMS viewers, the objective here
is to specify interactive behaviors. WebSheets allows the
user to specify database operations and spreadsheet
formulas that are triggered by events (usually button
clicks), and that are dependent on input form data.
In the Add Row of Figure 1, for instance, the designer has
entered the names of the input form text boxes At run-time,
when the Add Button is selected, the values in the text
boxes will be used to add a record to the database. Note
that the visual table will then be updated using the criteria
in the view select row (InStock>10 and Price>22.00).
Query formulas and add expressions can also refer to input
form data from another page in the development
environment. The designer just qualifies the component
name with the page name, e.g., "page1.minimumPrice".
Multiple Entry Points
A dynamic web page can be invoked from various pages
and even from itself. WebSheets allows the designer to
specify the result page of a button by right-clicking on the
button and specifying the name of any open page in the
development environment.
When a page p is specified as a result page of a button, a
new tab appears in p's development-time window. In Figure
1, there are two tabs—the selected one corresponding to the
"Add" button within the page, and the “Page1.submit” one
corresponding to a button in another page (not shown). The
designer selects each tab to specify the database operations
that should occur when the dynamic page (servlet) is
invoked from the corresponding button. No matter which
tab is chosen, the components in the page appear the same.
Spreadsheet Formulas
The facilities described above allow for the development of
web pages connected to databases, but they don't allow
computations on the data. WebSheets provides enhanced
spreadsheet functionality, similar to [1], that allows
formulas to depend on both tabular and non-tabular
components. The user enters formulas both in the Add Row
and in table columns of the sample row that are not mapped
to database fields. When the initial mapping to the database
is made, any number of columns can be left unmapped and
instead marked as "expression" columns. The designer can
enter formulas in these columns that refer to any of the
column names of the table. For instance, in Figure 1, the
designer has entered “Instock*Price” in the Total column.
At development time, the formulas are evaluated using the
live database data in the other columns of the sample row.
The computed value (e.g., 340.00) is placed in the cell and
the formula appears at the far right of the toolbar. At runtime, the formula is evaluated for all rows in the database.
Comparison to UltraDev 4
The advantage of the WebSheets scheme, over a system
like UltraDev 4, is directness. Consider, for instance, the
Add operation specified by the Add Row in figure 1. With
UltraDev 4, the input form data has to be mapped to
parameters of the page, then the parameters of the page
mapped to an add operation of a result set, and the result set
mapped to the visual table. WebSheets allows the designer
to circumvent this circuitous route, which maps closely to a
computer program, and instead directly specify what the
end-user of the program sees: that the data in the input form
should be placed in the table.
SUMMARY
WebSheets allows database operations and computations to
be specified in the context of the HTML interface.
Currently, only flat tables can be mapped to a page. Our
next step is to enhance the system so that complex tables
and relations can be specified in a visual manner. We also
plan to explore storing the persistent data as XML files
instead of relational database tables.
REFERENCES
[1] Burnett, M. Atwood, J., Djang, R. , Reichwein, J.,
Gottfried, H. and Yang,S. "Forms/3: A First-order
Visual Language to Explore the Boundaries of the
Spreadsheet Paradigm," Journal of Functional
Programming, 11(2):155-206, March 2001
[2] Cypher, A., Watch What I do: Programming By
Demonstration, MIT Press, London, England, 1993.
[3] Lutris, Inc., http://www.lutris.com/products/index.html
[4] Macromedia, Inc., http://www.macromedia.com/
To appear in the Intenational Conference on Intelligent User Interfaces (IUI 2002, San Francisco, CA).