|
|
Connecting VisualAge for Smalltalk to the WebBy Bob Brodd, Hatteras Software, Inc. |
Introduction
IBM's response to this desire is the VisualAge Web Connection Feature, an add-on to their VisualAge for Smalltalk product. The Web Connection provides a new set of visual and non-visual parts for VisualAge that are specifically designed for creating Web-based applications. Additionally, it provides the interface between your VisualAge application and Web server, eliminating most of the complexity of using the Common Gateway Interface (CGI), which is a standard protocol through which Web clients can execute programs residing on your Web server. How it worksA typical Web session involving a Web Connection application works in the following manner: Step 1: A client Web browser requests a Web Connection page by specifying the transfer protocol and Uniform Resource Locator (URL) (ex. http://www.server.com/cgi-bin/abtcgil.exe/PartName). In addition to specifying the server address (www.server.com), the URL also includes the path to the Web Connection CGI Link program (/cgi-bin/abtcgil.exe) as well as the VisualAge part name that designates the page to retrieve (PartName). Step 2: The Web server receives the URL request and invokes the Web Connection CGI Link program (abtcgil.exe).. Step 3: The CGI Link program relays this request to a pre-assigned TCP/IP socket where the Web Connection CGI Link Server, a process running in your VisualAge application, is waiting to service requests. Note: Your VisualAge application can be running on any computer that is accessible from your Web server via TCP/IP. Step 4: The CGI Link Server receives the request and creates a new Smalltalk process to handle the request. It then creates a new instance of the Web Connection part (page) requested and asks the new part to generate its HTML. Step 5: As part of generating its HTML, the part may potentially interact with model objects within the image to perform computations or provide data to display in the page. The resulting HTML code is passed back through the CGI Link Server, CGI Link, and your Web server to the Web browser, which renders the page to the client. Not just another web page layout programBefore going on much further, I would like to emphasize that Web Connection is not a replacement for a Web page layout program. Its purpose is to provide support for building applications capable of running on the Web. As a result, you are not going to find support for every aspect of HTML. In fact, only the controls and features that have merit in the area of application construction are included or are even under consideration to be included. The components listed in the Supported HTML Components table are represented in Web Connection as visual parts in the composition editor. They have the ability to translate themselves into HTML code at runtime so that a client's Web browser can re-create the GUI. They also have the knowledge to align themselves on the VisualAge composition editor based on the rules of HTML. This provides the web page developer with visual feedback as to what the page is going to look like in a Web browser as they are developed (see before and after examples). None of the standard VisualAge for Smalltalk visual parts can be used on Web Connection pages (non-visual parts do not have this restriction). The Web Connection parts do a good job of surfacing most of the features available for the HTML component they represent. For parts that do not, Web Connection typically provides the ability to add raw HTML to the part definition. Notable exceptions are the Table and Table Column parts. Although they are very useful for generating variable-length tables of static (string) information, they do not handle the nesting of other Web Connection parts. This is a rather serious deficiency given the enormous formatting and alignment benefits that HTML tables provide in an otherwise primitive and rigid environment. Not all is lost however. The HTML Text part can be created as a 'literal' string which allows you to add raw HTML code to your pages. You can interleave literal HTML Text parts with your other Web Connection parts to create tables on your own (of course you will have to learn about all of the HTML tags associated with tables first). Advanced Application Development SupportCreating interactive applications to run over the World Wide Web is a major challenge given the standard mechanisms provided by HTML and HTTP. HTML was originally designed to support information retrieval by providing a mechanism for linking words or phrases in one document to associated text in the same document or other documents elsewhere on the Internet. HTTP was designed to be a very quick and simple transfer protocol. One of its major design points is that the connection made between the client and server is temporary; therefore, every request generated by the client results in a new connection. While they do a fine job at what they were originally designed for, they do not provide all the support necessary for developing serious Internet-based applications. To aid in building web-based applications, Web Connection provides several important non-visual parts to the palette. The HTML Form Data part provides access to the components defined within an HTML Form. In particular, it provides easy access to all of the data entered in fields, items selected in lists, as well as events such as button-clicks. These values and events can be connected to other appropriate parts via the standard VisualAge connection mechanism. The HTML Composite part is a part holder that contains other Web Connection visual components. Once defined, the composite part can be included in any of your Web Connection page definitions. The advantage of this feature is that you can define common pieces of your user interface in one place and use it in many places. If changes are made to the composite part, all Web pages including the part will incorporate the changes. This part is an obvious choice for creating standardized headers and footers for your Web pages. As noted above, every request made by a client results in a new connection between the client and server. This causes a major problem for designing Web applications because there are no simple ways to maintain persistent information over the many connections a client creates while running an application. The CGI Link Session Data part is the Web Connection's answer to this problem. The first time a client accesses a Web Connection part, the Web Connection generates a unique session key that is passed back to the client in a hidden HTML field. Each time the client posts a new request, the hidden session key is passed back with the request in the hidden HTML field allowing the Web Connection to identify the request as belonging to an 'existing' client. Using the session key, the Web Connection can identify the instance of the CGI Link Session Data part that belongs to the client. The value associated with a CGI Link Session Data is persistent and can contain any Smalltalk object required; therefore, any information that needs to persist during a particular client session can be stored. An additional benefit of the CGI Link Session Data part is that your application can keep track of multiple sessions from different clients at the same time. In fact, since VisualAge for Smalltalk supports running multiple concurrent Smalltalk processes, these requests can occur simultaneously. The HTML Page Wrapper part is an integral part of a mechanism designed to make it easy to transfer a client's request from one page to another. The HTML Page Wrapper is a part that represents a Web Connection page. When a request is posted to a Web Connection page, it can conditionally transfer the request to any of the HTML Page Wrappers that it defines. As an example, let's assume that a page defines a form containing a push button that should display a new page when pressed. The button-clicked event of the form connects to the transferRequest action of the page wrapper which represents the new page. When the user presses the button, the client sends a request to the current Web Connection part which generates the button-clicked event. This event causes the transferRequest action of the page wrapper part to fire, transferring control to the new page. The new page then generates its HTML and returns it to the client; thereby becoming the new current page. An additional feature of this part is the ability to pass any Smalltalk object along with the transfer request. Building on the previous example, let's add a list to the original page. Instead of connecting the button-clicked event to the transferRequest action, we will connect it to the transferRequest: action. Then we can connect the selected item of the list to the transferRequest: action as the parameter. When the new page receives control, it will have access to the object selected on the previous page (see CGI Link Request part below). The CGI Link Request part provides access to all of the information available in an incoming request including the CGI variables and form data (which is useful if the form submitting the request was not built with Web Connection). It also provides access to the transferred object in situations such as the one described in the previous example (see HTML Page Wrapper part). In addition, this part has the ability to signal an event each time a new request is received. When a page containing a CGI Link Request part receives a new request, the part signals a requestReceived event which can be connected to any page initialization tasks that are required. Getting more out of Java
|
|
 |
f
you are already a user of IBM's
