How the Web DataWindow works

The Web DataWindow uses a component running in a transaction server (such as EAServer or COM+) cooperating with a dynamic page server (such as Microsoft Active Server Pages in IIS or Java Server Pages in Tomcat) and communicating with a Web client by means of a Web server. No PowerBuilder DLLs or plug-ins are required on the Web client.

The built-in Web DataWindow component is the HTMLGenerator125 component that is preinstalled in EAServer 6.x. The component is used to generate the JavaScript and the HTML; XHTML; or XML, XSLT, CSS, and XHTML, depending on the type of Web DataWindow you are creating. You can also use a custom component that you develop instead. For more information, see “The Web DataWindow server component and client control” on page §.

Disabling instance pooling when deploying Web DataWindow targets Instance pooling allows transaction server clients to reuse component instances and so improves server performance by eliminating the resource drain caused by repeated allocation of component instances. Instance pooling is turned on by default for the HTMLGenerator125 component in EAServer. This prevents you from deploying a target that uses the component a second time without stopping and restarting the server. During development, you might want to turn instance pooling off. For information on changing the pooling property of a component, see your server documentation.

In EAServer, you can disable instance pooling using EAServer Manager or by setting the com.sybase.jaguar.component.pooling property to false in the HTMLGenerator125.props file in the \EAServer\Repository\Component\DataWindow directory. The component pooling property should be set to true for production use.

What happens when a user requests a page

Figure 6-1 shows you graphically (in eight steps) what happens when a user accesses a Web page containing an XHTML or HTML Web DataWindow.

Figure 6-1: How the Web DataWindow works

The diagram illustrates the eight steps described in the text that precedes it. At the top is the client, where the client control component of the Web Data Window resides. Here, the user requests the U R L for a page in the Web browser (step one) and interacts with the Data Window (step seven). Below it is the system where the Web server and page server reside. Steps two, six, and eight pass between this sytem and the Web browser on the client. Next is the server component on the component server, which receives the information passed in step three and returns the H T M L and Java Script to the page server in step five. Last is the database, from which data is retrieved in step four.

The numbers 1 through 8 in the figure correspond to the events that occur after you develop and deploy a Web DataWindow and a user accesses a page containing the Web DataWindow:

In a Web browser, a user requests the URL for a page.
The Web server passes the request to the page server, which locates the template for the requested page and executes server-side scripts in the template.
The server-side scripts connect to the (transaction) server component, passing it information about the DataWindow and database connection.
Methods on the server component retrieve data required for the DataWindow from the database and translate the DataWindow definition, data, and state into JavaScript and XHTML or HTML.
The server component returns the JavaScript and XHTML or HTML and to the page server.
The page server replaces the server-side script in the requested Web page with the generated JavaScript and XHTML or HTML and returns the page to the Web browser through the Web server.
The user interacts with the DataWindow—for example, requesting the next page or updating the data.
The Web server passes the URL with added action parameters to the page server, and the cycle begins again.