WebDev is a programming in the what-you-see-is-what-you ...



ABSTRACT

WebDev is a programming in the WYSIWYG interface tool for building dynamic web pages that connect to databases. The system allows designers to “program” by entering query by example (QBE) and spreadsheet formulas into visual components of HTML documents. The system then automatically generates dynamic web pages that can be executed in a browser.

1. INTRODUCTION

WYSIWYG HTML editors such as Microsoft’s Front Page [16] make the design of static web pages easy for end-users (designers who are not programmers). Tools such as WebMacro[19] and XMLC[13] go a step further by easing the task of designing dynamic web pages. With these tools, the designer works with sample data to specify the presentation of the dynamic page. The programmer then specifies the dynamic content of the page separately.

These tools do not, however, help a designer create a complete dynamic web page, including both presentation and content. The designer is still dependent on a programmer. This is unfortunate, especially since end-user programming techniques have proven viable in other domains.

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.

In the world of dynamic web page development, Macromedia's Ultradev 4 [14] is as close to a programming in the WYSIWYG system as there is. Unlike Visual Basic, it allows the dynamic parts of a program, at least one that views and manipulates a database, to be specified without writing code.

Unfortunately, Ultradev 4’s process still requires programming knowledge; it is only partially programming in the WYSIWYG. For instance, instead of directly specifying how input form parameters of one page affect a visual table on another page, the Ultradev developer specifies how the input data of one page maps to parameters of the other page, how those parameters map to database operations on a result set, and finally, how the result set is mapped to a visual table.

Some of this specification occurs in an interface resembling the target interface, but much of it does not, and much of it involves programming concepts such as parameters and result sets. Because of this, one might consider Ultradev 4 more of a visual interface to a program, as opposed to a programming in the WYSIWYG tool.

We have designed a tool, WebDev, that allows a dynamic web page to be designed directly in the context of the WYSIWYG interface. With WebDev, the designer first maps visual tables to database tables, either using a dialog or by asking the system to generate a table from a sample row. After mapping, visual tables appear with some special rows that guide the designer in specifying database operations (see Figure 1). The designer enters QBE and spreadsheet formulas in these rows.

When the designer enters these formulas, he is not specifying them for the sample data that appears at development time, as in 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, also manipulate the run-time view of that table.

This programming in the WYSIWYG scheme allows for more concrete specification of dynamic web pages. The designer never needs to enter an entire SQL or programming statement, or refer to result sets, parameters, or other “program” items other than named items from the user interface. Through the use of formulas, the designer can directly connect input form parameters with database operations, and thus bypass the circuitous specification necessary in Ultradev 4 and hand-coded development (see Figure 2).

At any time during development, the designer can ask WebDev to “run” the program. The system generates servlets, registers them with a server, and runs the new dynamic pages in a browser.

WebDev generates an HTML template file and a Java servlet. The template file is sent to the Lutris XMLC compiler, which generates a Document Object Model (DOM) tree representation. The servlet then manipulates that DOM tree to add the dynamic content.

Experience with the first users of the system suggest that the tool can significantly reduce development time for programmers, and increase the pool of designers that can build complete dynamic web pages. While future papers will provide formal usability tests, this paper provides an overview of the development process, including the code generated.

THE DEVELOPMENT PROCESS

When an HTML table is inserted into the editor, the designer can either map it to existing database table(s) by entering information in a dialog, or enter sample data for it, and tell the system to create the database table automatically. The development-time HTML table then represents both a run-time visual component and the mapped database table (s).

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.

If the designer saves the program immediately after mapping the database, the resultant web page will display all records of the mapped database table in the visual table. Most the time, of course, the designer desires a more complex web page.

After the mapping, the development-time table appears with one sample row of "live" database data, and four other rows, empty except for labels in the left-most column that help guide the designer (see Figure 1). The first row is an optional header row. The second row displays sample “live” data from the mapped database. The view select, delete select, and add rows are used to specify the database operations that should be performed.

PBE Formatting

The designer formats the sample data in each cell of the sample row. At run-time, the sample formatting of each column is applied to all database data (rows) that appear (e.g., all titles in the table of Figure 1 will appear italicized).

View Select Row

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. For example, suppose the designer enters expressions in the view select row as in Table 1. The system will build the query:

SELECT * from BookTable

where InStock>10 and Price>22.00

and use it in the generated servlet so that only the selected books are displayed.

Delete Select Row

The delete select row is similar to the view selection row, but the QBE entered is used to choose which rows are deleted from the database when the page is invoked. If “Kafka” were entered in the Author column of the delete selection row in Figure 1, the following SQL statement would be generated:

DELETE * from BookTable where Author=Kafka

If the delete row is left blank, then no deletions will occur.

Add Row

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.

Input Forms

Selects, deletes, and adds are often based on something other than the constant data provided in the samples above. In many interfaces, the operations will depend on data entered by the user in an input form.

WebDev allows expressions and formulas to include references to the names of input form data. For instance, in the add row of Figure 1, 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".

Entry Points

A dynamic web page can be invoked from various other pages and from the page itself. WebDev 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 is specified as a result page of a button, a new tab appears in the page's development-time window. In Figure 1, there are two tabs—the selected one corresponding to the Add button in the same page, and the “Page1.Remove” one corresponding to a button in Page1. Each tab panel specifies the actions that will occur when the page is loaded as a result of clicking the button the tab represents. For the example in Figure 1, the designer has chosen the Add tab to specify the actions that should occur when the Add button is clicked. The designer chooses the Page1.Remove tab (Figure 2) to specify the actions that should occur when Page1’s Remove button is clicked.

Note that when the designer adds new components or modifies the layout of a page, these changes are reflected in all tab panels, no matter which is currently selected.

Spreadsheet Formulas

The facilities described above allow for the development of web pages that access database data, but they don't allow computations on the data. Fortunately, WebDev provides enhanced spreadsheet functionality, similar to [4], which allows computations to be entered. The user can enter complex formulas both in the add row and in table columns that are not mapped to database fields.

When the initial mapping to the database is made, any number of columns in the visual table can be left unmapped. Those unmapped are called "expression" columns. In expression columns of the sample row, the designer can enter formulas that refer to any of the column names of the table. For instance, in Figure 1, “Total” is an expression column, and the designer has entered “Instock*Price” as its formula.

On entry, the formulas are evaluated using the live database data in the other columns of the sample row. This is done only to provide immediate feedback to the user. The computed value (e.g., 340.00) is placed in the cell and the formula appears in the toolbar (as it is in Excel and most spreadsheets). At run-time, the formula is evaluated, in the generated code, for all rows in the database that are to be displayed.

Code Generation

When the designer has completed his specifications, he selects Code Generation | Generate and dynamic web pages are created for each open editor page. The pages are automatically registered with a server (currently, a WebLogic [3] server), so the designer can select Code Generation | Run and immediately see the results of his work in a browser.

Note that saving a WebDev document is different than generating code for it. Saving results in the internal format of a WebDev page being written to a file. The designer can load this file in later for “visual” editing.

Figure 3 illustrates the WebDev code generation process. From the designer’s WYSIWYG specifications, WebDev generates a template HTML file. The HTML template contains id tags for all visual components—either the default ids each component is given when inserted into a page, or ids

the designer has specified explicitly during development. If this template file were sent directly to a browser, all tables would appear with the single sample row but without the guide labels (sample row, select row, etc.) in the first column.

After generating the template file, WebDev invokes the Lutris Enhydra XMLC compiler. XMLC takes the template HTML file as input and generates Java code representing the page as a Document Object Model (DOM) tree. If this DOM tree were invoked from a servlet, it, too, would display the page with the single sample row specified during development.

In order to insert the specified dynamic content, WebDev also generates a servlet that manipulates the DOM tree. The generated servlet executes the specified database operations then modifies the DOM tree. It has the following form:

Class GeneratedServlet extends HTTPServlet

{ /…

public void service(HttpServletRequest req, HttpServletResponse res)

throws ServletException, IOException

{

// Access request parameters

// Access DOM tree created from HTML templ

// if actionTag == xxx

// for each table/list

// Execute specified add operations using JDBC and

//SQL Insert statements

// Execute specified delete operations using JDBC and

// SQL Delete statements

// Execute the specified Select statement to obtain a result set.

// Use DOM manipulation code to:

// Access and clone the sample row

// Create and insert new rows using the result set

// Remove the sample row

// Evaluate the spreadsheet formulas of the “expression

// columns”

// Use DOM manipulation code to enter these values in the

// DOM tree.

// else if actionTag == yyy …

// …

// Write the updated DOM tree to the browser

}

}

Code Listing 1. The form of the generated servlet.

Since the designer can specify entry points to the page from various input forms, the generated servlet must handle requests from each of those entry points, each of which may send a different set of request parameters. Thus, the code generator associates a particular action tag with each entry point and inserts the tag in the submit action statement of the invoking servlet. The service method of the invoked servlet (which may be the same as the invoking servlet) checks the action tag value and proceeds dependent on it. In the code of Listing1, two action tags have been specified, one for a button named "xxx", and one for a button named "yyy", both of which invoke "GeneratedServlet".

The code for each action tag corresponds to the expressions entered in the corresponding tab in the development time environment. If expressions were entered in the add row, the code will contain SQL INSERT statements (wrapped in JDBC code). if expressions were entered in the select delete row, the code will contain SQL DELETE statements. The code will always contain a SELECT statement based on the expressions entered in the view select row. If no such expressions exist, the generated SELECT statement will not contain any WHERE clauses.

After obtaining a result set of live database data from the SELECT statement, the generated code manipulates the DOM tree to insert the data into the visual HTML table. The code first clones the sample row of the DOM tree, in order to access its formatting. It then adds a row in the DOM tree for each of the rows in the result set, setting the data's formatting as specified in the sample row. As it loops through the rows, the code also evaluates any spreadsheet formulas in expression columns and inserts this dynamic data in the DOM tree node for that column. When all rows have been inserted, the code removes the sample row and writes the updated DOM tree to the browser.

As a concrete example, Listing 2 displays the code generated for the Remove tab of the sample page in Figure 2.

If(actionTag.equals(“remove”)) {

// Access request parameters

String minStock = req.getParameter(“MinStock”);

// Access DOM tree created from HTML templ

BookListDOM doc = new BookListDOM();

// Execute specified delete operations using JDBC and

// SQL Delete statements

stmt.execute(

"delete from BOOKS where INSTOCK10 and PRICE>22");

// Use DOM manipulation code to:

while(rs.next()) {

// Use DOM manipulation code to enter these values in the

// DOM tree.

doc.setText_table1_col0(rs.getString(1));

doc.setText_table1_col1(rs.getString(2));

doc.setText_table1_col2(rs.getString(3));

doc.setText_table1_col3(rs.getString(4));

// Evaluate the spreadsheet formulas of the “expressions”

doc.setText_table1_col4(

String.valueOf(rs.getInt(3) * rs.getInt(4)));

// Clone the sample row

tempRow.getParentNode().insertBefore(

tempRow.cloneNode(true), tempRow);

}

// Remove the sample row

tempRow.getParentNode().removeChild(tempRow);

// Write the updated DOM tree to the browser

out.println(doc.toDocument());

} else if(actionTag.equals(“add”)) {

// …

}

Code Listing 2. The actual generated code for the Page2 servlet when it is invoked from Page1’s Remove button.

As the generated code illustrates, the WebDev designer is shielded from many of the details of building a page. Whereas the WebDev designer can directly specify a mapping between input form data and result table (see Figure 2), the programmer must follow a more circuitous route. The programmer must write 1) a submit action statement specifying the parameters from the input form page, 2) servlet code that accesses the parameter values, 3) code that places those parameter values within the context of SQL statements, and 4) code that maps the result set from the SQL statements to a visual table.

RELATED WORK

UltraDev 4 is the union of Dreamweaver and Cold Fusion. Much can be specified without programming, but not in the direct, in-context manner of WebDev. Take, for instance, the development of a simple page that allows an end-user to add a record using input form data. In UltraDev 4, the designer must create a ResultSet object that is mapped to the database table. He then maps the columns of this ResultSet to columns of the visual table- a mapping unnecessary in WebDev since the visual table represents the database table and a view of the table.

Next, the UltraDev4 developer maps the AddRecord operation to the Add button by choosing it from a list of operations. He then maps the input form's text boxes to the parameters of the page being built. Finally, he maps the page parameters to the parameters of the AddRecord operation created earlier.

Schema-Based Code Generators

ASPapp [1] is indicative of tools that generate dynamic web pages directly from a database schema. These tools provide an immediate (one-click) web front-end to any existing database. Most provide wizards that allow some specialization of the generated pages. A designer can also edit the generated code after the fact to make layout and other modifications, using whatever tools and editors are available.

Designing web pages in WebDev requires some work, but more customization is possible than with schema-based generators. The designer can specify pages that display and allow any add/delete modification of any number of database tables, and that display database data in lists and combo boxes as well as tables. Because mapping is based on columns, a single visual table can show data from various database tables, and a single database table can be viewed across multiple visual tables. Because the designer can specify the relationship between various submit events and pages, more customization is possible in terms of how various pages are related.

Furthermore, since specialization is facilitated through a wizard in schema-based generation, row selection criteria must be specified out of context with an SQL-like statement. In WebDev, this criteria is specified in the context of the target interface.

Declarative Definition of Web Sites

Strudel[7,8] is indicative of systems that provide an intermediate layer between the raw database and the web page. These systems allow a designer to specify a query that describes the structure of the website to be built. From the query, the system builds a data model, often in XML, which represents the part of the database that the website covers. Various methods are then used to map this model to the actual layout of the web pages.

Query by Templates

Query by Templates (QBT) [18] is a generalization of QBE. Its focus is visual specification of interfaces for XML data instead of database data. The semi-structured nature of XML data leads to a more natural mapping of non-tabular graphical components to the data, so QBT users can specify queries within “components” such as poems. One interesting direction would be to apply QBT to WebDev’s objective, which is the development of complete interactive web pages.

Forms/3 Spreadsheets

Forms/3 is a programming environment based on the spreadsheet. Spreadsheet formulas need not be placed only in cells of a table, but can be entered in any visual component or even as a property of some complex component such as a graphic. Tables need not be of a fixed size, but can contain a variable number of rows and columns.

Like with regular spreadsheets, the data entered in a Forms/3 interface is persistent. But though there is the concept of dynamically sized tables, there is no notion of an underlying store beneath the visible data that the designer manipulates. Forms/3 is thus more concrete, as the designer need not mentally map the development-time tables to run-time database tables. However, it cannot be used to create interfaces to existing databases or to specify traditional database operations.

Programming by Example

PBE has been applied successfully in many domains, the results of which have been reported in two books[6,11]. It has even been applied to dynamic web page development, but only in the context of building wrapper programs[2,10,15], i.e., pages that get input from the user, invoke other existing web page(s), then parse the resultant data and display it to the user.

Led by the first authors previous experience [17,20], our original idea was to apply PBE to the development of web pages that connect to databases. The basic idea was that the entire “live” database table would be displayed at development time, making the system more WYSIWYG. The designer would not specify formulas, so the abstraction of variable names would be eliminated. Instead, the designer would provide examples of the database operations using sample data. To specify an Add operation, the designer would add a row to the visual table, then cut and paste data from the input form to the new row. To specify selection criteria, the designer would somehow provide sample rows that fit the criteria, and the system would infer the SQL Select statement.

Though such an example-based scheme might work better for some designers, we surmised that, in the domain of HTML dynamic web pages, it made the environment too complicated. HTML tables do not allow rows to be added or deleted directly, so demonstrating these operations would require using operations that exist only in the development interface, and not in the target interface. Furthermore, selecting rows in order to specify a query seemed more complicated than QBE, even if it eliminated the need for variables and somewhat abstract expressions.

WebDev does use PBE in the context of formatting rows, specifying spreadsheet formulas for expression columns, and simple table creation. But after some testing with a prototype that allowed database operations to be specified by example, we determined that the spreadsheet/QBE level of abstraction had better potential.

STATUS AND FUTURE WORK

The implementation of WebDev, as described in this paper, is nearly complete. Beta versions of the system have been used to create numerous web applications such as the Bookstore example illustrated in this paper. Feedback from users has been encouraging—most are amazed at how quickly dynamic web pages can be built.

Our next step is to perform extensive usability testing in order to refine the system and prove its usefulness. We also plan to make WebDev publicly available so as to get widespread feedback.

In the next version, we will implement dynamic visual components other than tables. A designer will be able to “program” lists, combo boxes, and sets of text cells in the same manner as tables. We will also design and implement a method for specifying updates to table rows, a capability not covered in this paper.

One direction of future work concerns the specification of relational tables in the WebDev framework. Currently, a table will be created from a sample row, but no relations are inferred. Could a table relation be inferred if a designer enters multiple sample rows, where the value of some columns are the same? Are there other ways in which relations can be demonstrated, such as inferring them from the QBE and spreadsheet formulas entered by the designer?

Following the lead of [18], we would also like to explore mapping the designer’s visual specifications to XML data, instead of databases, and explore generating XML data, instead of a table, from sample row(s).

SUMMARY

WebDev combines spreadsheet and QBE formulas with the ability to visually specify the interactive behaviors of dynamic web pages. With this combination, designers can specify interactive database operations and computations without writing code, and directly in the context of the HTML interface.

REFERENCES

ASPAPP Inc.,

Bauer, M. Dengler, D.,Paul, G., Meyer, M., Programming by Demonstration for Information Agents, in Your Wish is my Command, Henry Lieberman, Ed. San Francisco: Morgan Kaufmann, 2001

BEA WebLogic,

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

Cypher, A., Eager: Programming Repetitive Tasks by Example, Proceedings of CHI ’91, New Orleans, LA., May 1991, pp.33-39.

Cypher, A., Watch What I do: Programming By Demonstration, MIT Press, London, England, 1993.

Fernandez, M., Florescu, D, Kang, J., Levy, A., Suciu, D., Catching the Boat with Strudel: Experiences with a Web-site Management System, in Proc. of ACM SIGMOD Conference on Management of Data, Seattle, WA. 1998.

Florescu, D., Levy, A.,Mendelzon, A., Database Techniques for the World-Wide Web: A Survey, SIGMOD Record, 27(3):59-74, September 1998.

Halbert, D., Programming By Example, Ph.D. dissertation, University of California, Berkeley

Kushmerick, N. Wrapper Induction: Efficiency and Expressiveness, Artifical Intelligence, 118, 2000, pp. 15-66.

Lieberman, H. ed., Your Wish is My Command: Programming by Example, Morgan-Kaufmann, 2000.

Lieberman, H., Mondrian: A Teachable Graphical Editor, in Watch What I do: Programming by Demonstration, MIT Press, London, England.

Lutris, Inc.,

Macromedia, Inc.,

Miller, R., Myers, B., Creating Dynamic World Wide Web Pages by Demonstration. Carnegie Mellon University School of Computer Science Technical Report, no. CMU-CS-97-131 and Human Computer Interaction Institute Technical Report, CMU-HCII-97-101. May, 1997.

Microsoft, Inc., .

Myers, B., McDaniel R., and Wolber, D., "Intelligence in Demonstrational Interfaces," Communications of the ACM.March, 2000. vol. 43, no. 3. pp. 82-89.

Sengupta, A. Dillon, A., Query by Templates: A Generalized Approach for visual query formulation for text dominated databases. In Conference on Advanced Digital Libraries (ADL ’97) 1997.

WebMacro,

Wolber, D., and Myers, B., "Stimulus-Response PBD: Demonstrating When as Well as What", Your Wish is My Command, Lieberman, H. ed. San Francisco: Morgan Kaufmann, 2001. pp. 321-344.

Zloof, M.,"Query-by-Example: A Database Language", IBM Systems J., 21(3), 1977.

-----------------------

WYSIWYG specs

Figure 3. Code generation in WebDev

Servlet including JDBC and DOM manipulation code

Java DOM tree code

HTML template

XMLC

WebDev Code Generator

Figure 1. WebDev Development of a Bookstore page

ResultSet

SQL Statements

Servlet Parameters

Figure 2. An input form page (Page1) and a result page (Page2) during development. WebDev 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.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download