![[MOONSCAPE HERE]](/www2/Proceedings/WebProd/thralls/wonder.gif)
CDC WONDER
Converting Existing MS-Windows Applications to HTML
Author: Robert K. Thralls, Senior Technical Consultant
NOTE: For optimal output, view with a good fill-out FORM client: like Mosaic, MS-WINDOWS Alpha6
This paper conveys the idea of converting currently existing applications from Microsoft Windows (or compatable) environment to HTML (fill-out FORMs). Most MS-Windows applications take advantage of resource files. These resource files define the look and feel of the product. Inside these files, one finds definitions of dialog boxes, menus, icons, and the like. These textual descriptions usually compile into object files and attatch to executables for the application to use at run-time. One now uses these files to create HTML fill-out FORMs and backend host programs conformant to Common Gateway Interface (CGI) standards. This paper addresses both the tools used to achieve the port and the short comings of HTML in the area of reproducing look and feel qualities of many MS-Windows applications.
This concept of conversion directly mimicks the system it augments. The Centers for Disease Control (CDC) PC/Wonder product utilizes a generic forms processor and resources which define contents of forms. The generic form processor directly corresponds to the functionality of an HTML client that supports fill-out FORMs (MOSAIC). The resources reflect the contents of the HTML FORM. Through this analogy, one sees the direct implication of conversion from MS-Windows' Dialog Boxes, for example, to an HTML fill-out FORM. Although designed specifically for CDC PC/Wonder, the entire conversion process elegantly lends itself to generic application processing for data requests at remote server sites. Use of the converter with resource files for even simple fill-out forms dramatically increases consistency in user interface look and feel.
Table of Contents
In the beginning, WONDER existed as a mainframe application. Today, the PC version of the software outmodes archaic 3270 terminal access. However, the Data Sets still exist on the mainframe. Thus, facilitating data directly to the PC environment takes time and patience. The PC client must make requests to the mainframe data sets in batch mode.
CDC PC/Wonder runs on a PC platform. The package allows public health officials world-wide access to CDC information. Primarily a request/response engine, a user fills out request screens and submits them to the appropriate Data Set server. Data Set servers return a response that may be either dynamic information for the next request screen or the final information that completes the users request. Information is displayed in one of three ways. Data returned for the next screen feeds to the next appropriate screen. Data in report format displays as hypertext with tables and figures. Raw data generally funnels to an external spreadsheet called Tables and Graphs (T&G;) for display and manipulation. T&G; also displays maps of the US for data associated with specific regions.
Recently, the identification of users on the Internet spurred a remarkable development. CDC decided to grant Internet access to its data for public health officials. CDC PC/Wonder contains abilities for ASYNC and NOVELL LAN connectivity. Clearly, Internet access complicates the release of a product due to non homogenious makeup of the Internet community. Thus the addition of TCP/IP protocol stacks into CDC PC/Wonder could not support all potential internet users of WONDER.
Introducing MOSAIC/Wonder, the newest interface to WONDER. This MOSAIC interface is directly derived from the CDC PC/Wonder user interface description (Resource Files). MOSAIC/Wonder allows an Internet user to use the application precisely in the same manner as CDC PC/Wonder. The system creates HTML and CGI backend programs on-the-fly for each screen. HTML fill-out FORMs mimick most of the user interface and functionality of the PC version. Resource file converters and integration tools provide the bulk of processing capability in a very generic fashion. These tools lend themselves well to any existing application or any future HTML application designers.
MS-Windows applications can be ported to the HTML environment. Limits to conversion exist on the HTML side. Conversion in this context is limited to the Resource files that define look and feel, as well as data on the screen.
Of course, one need not use this conversion utility simply for porting an MS-Windows application. This tool set allows HTML authors to control look and feel issues for their FORMs user interface. Also, the tool set manages user data maintained at the server site. The tool box automates server content management with reguard to the integrated FORMs; although, application data remains in the hands of the system administrator.
Resource files exists for most MS-Windows applications. Resource files created with WYSIWYG tools such as App Studio, bundled with Visual C/C++, give the creator instant knowledge of look and feel issues for a set of screens. No questions remain as to what a dialog or menu looks like nor how it behaves. WYSIWYG tools speed up the development process. Even non-existent HTML applications can take advantage of WYSIWYG tools. HTML authors need only to point and press with a resource file generator (App Studio) and then use the resource compiler for HTML and backend generator. This section examines these steps more closely.
One uses Microsoft App Studio or Borland Resource Workshop to create the desired Menu or Dialog. An assumption is made about access to and knowledge of one or more of these products. Readily available, these well documented tools are left for the experienced user to explore. The converter supports resource file output not limited to the following:
Resource (RC) files describe dialog boxes, menus, and other display items. The ease in creating these files depends upon the tool of choice. Some elegant tools are WYSIWYG and allow effective management of the user interface. RC files allow one to maintain the consistency in look and feel that application users appreciate. RC files enforce standards in look and feel and yield the consistency of a professional application from start to finish. These files are converted to HTML and 'C' code (CGI backend process) with the same effect as the resource compiler would attatch a usable run-time object to a MS-Windows application (.exe). The following example demonstrates the flexibility and dynamic nature of the converter.
Often the RC files will #include files for values and strings.
The converter interprets most ANSI standard 'C' preprocessor directives.
This includes, but not limited to:
In the example, this RC file previously existed in an application written for a multi-platform enviroment. Magma Software Systems "Mule", an MS-Windows Compatable Application Programming Interface (API), is used as the development environment. Note that Magma Systems recommends Borland's "Resource Tool Kit" to build resource files in a WYSIWYG fashion; however, Mule comes with its own resource compiler.
The previous resource file demonstrates the presentation of a DIALOG box. Consistency in look and feel stem from the project's style guide; file format and elements utilized in a DIALOG box contribute to the consistancy in HTML generation. The onus of application look and feel remains the issue of the application programmer (DIALOG designer), but one must still operate within a consistent structure. Thus, no matter what one does with a DIALOG BOX, one is assured of a consistent interface.
Now that one generated an RC file, one considers how to interpret that file. The converter supports either of two choices, dynamic or static. Static conversion simply creates an HTML file and an CGI compliant backend. The author uses these files statically in ANCHOR tag statments. Include static HTML FORMs in any HTML document as one would use any other HTML document. Applications utilize dynamic RC interpretation. Most applications contain MENUs, DIALOGS, MESSAGE BOXes, etc. Addressed later, the Integration of HTML FORMs yeild the same look and feel of the MS-Windows application. The integration allows branching to other FORMs from MENUs and dynamic data insertion into the FORM. Dynamic creation of FORMs also allows for "standard security" functionality. This separates user sessions by USERID.
The conversion program is run against the resource file and the following items are produced:
The converter reads an RC file and directly translates from resource commands to HTML statements for fill-out FORM support. The idea is to mimick the MS-Windows user interface as closely as possible. For instance, DIALOG translates to <FORM>, CAPTION translates to <TITLE>, and EDIT (EDITTEXT) translates to <INPUT>. Each FORM is placed in its own file, thus a scheme of "ROOT" and "BASE" is formed. "ROOT" applies to the root name of the RC file. "BASE" refers to the FORM number inside the RC file. Since all FORMS get their own file, they are named according to the scheme: ROOT.BASE.html. The combination of "ROOT" and "BASE" uniquely identify a FORM in the system. This identity is used through out integration, as a means of distinguishing individual FORMs. These FORMs are deposited in the USER's directory for his specific use. The CGI backend process removes the HTML file after the FORM is processed. In some cases, there is no FORM file, so reload will fail. Such dynamic FORMs are generally processed data requiring immediate attention and written directly to the WWW Client (MOSAIC).
The expample below demonstrates the conversion process. This HTML is generated from the previous RC file example: "ROOT" is MMWR and "BASE" is "00", this means that this is the only FORM in the file "mmwr.rc".
The integration of fill-out FORMs also includes the ability to Chain FORMs together. This means that once a fill-out FORM is submited successfully, the next FORM in the chain sequence will appear on the screen. This is accomplished via the menu file; facilitated through the use of "next_root" and "next_base" table entries. In the previous menu file, id IDM_LOGON (basicnew.08) calls the FORM basicnew.09 (the Password entry screen). The Password screen (basicnew.09) calls the Main Menu (basicnew.00). This example of a simple FORM chain demonstrates the LOGIN process ( USERID, PASSWORD, then present the user with the MAINMENU (PullDown)). From there the application may have many more chains of FORMs.
Note that PullDown is just a name, and a poor one at that, the RC file was used as is, but will be edited to reflect a meaningful name (like "Main Menu").
There are many features of the resource converter, these will have to be demonstrated at the conference in order to fully appreciate the power of this tool. Below is a partial list of features:
The following items will discussed at length in terms of a proposal for future HTML functionality enhancements. These features are considered to be extremely important to the development of new and porting of existing applications to the HTML/CGI combination environment. enjoy.
The use of <PRE WIDTH=180>...</PRE> within the context of fill-out FORM support. Currently, this use works on text, however, tags interfere with the preformatted text by beginning on the next line. IE: <INPUT> could not appear in the middle of a line on a FORM that uses <PRE>. This is a problem when attempting to group like items on a fill-out FORM together. The fill-out FORM creator is at the mercy of the MOSAIC formater for the placement of fields in the window. This must end if there is to be any control over look and feel issues of an applications user interface. There needs to be some latitude to override the line wrapping functions in HTML viewer like MOSAIC. If this functionality already exists, or its intent exists, then the BUG needs to fixed in short order.
This section deals with the insuffient data types of HTML Input variables.
Although these data types are defined as part of HTML+, it is imperitive that they be implemented in HTML viewers in the very near future. Complex applications will begin to eat bandwith without type checking. Free form input, as currently implemented, must be checked by CGI programs and errors returned over the net. Simple type checking can go a long way to preventing such bandwidth from being consumed due to relatively simple typing errors.
Intelligent frontend processing cuts the amount of bandwidth used for incorrect data entry or invalid data entry. As HTML applications begin to develop into more and more complex applications, this may prove to be a large resource hog. Therefore, I propose the following enhancements to HTML to cover the pitfalls of usable applications in that environment. The more intelligent processing performed by the Client viewers like MOSAIC, the less bandwidth is used. Not to mention the fact that the applications become more user friendly and backends use less server CPU. This yields better network throughput and more available cycles on the http server; thus, more users with existing equipment.
Some sites may not encounter this problem of mass access, but CDC PC/Wonder already tops 2000 consistent users and Internet access version CDC MOSAIC/Wonder will expand the user base to several times that over the next few years; even more so as CDC information is wanted by NON-US Public Health Officials. Unnecessary bandwidth or CPU consumption is not acceptable. The intense use of the httpd machine should not be burdened with the client end of a client/server architectural language (HTML). From this angle, I can advocate the spending of distributed Client CPU through the use of elaborate HTML, rather than burdening an already taxed central httpd server.
This would be simple field type checking, as mentioned previously. Basic types checked for valid entry of INT, TEXT, DATE, and FLOAT (from HTML+ specification).
Field validation should be performed by the viewer. Currently only a backend can determine if a value of "20.02" is a valid entry in an input field based on other field criterion. By allowing definable values or acceptable ranges of input to <INPUT> fields, one reduces the amount of Internet traffic associated with incorrect or invalid data entry. Pop-up of contextual Help functions (self-contained window, so as not to Hyper off to other FORMs nor alter the display area of the HTML viewer) may also help in this area.
Form validation may very well belong in the CGI program, however, various aspects of FORM validataion can be implemented for simple fill-out FORMs in the HTML viewer. The viewer would have to have contextual (structure) data stored about a FORM, and then make sure that related data in one field corresponds with ranges of data in other related fields. Yes, this sounds like 4GL style FORM coding. 4GL code may very well need to be in the future of HTML fill-out FORM support. Perhaps support of simple structure statements and if-then-else syntax would improve FORM context before submission to CGI programs. This would be fairly easy to implement string massaging functionality.
After carefull consideration, it is believed that programable access to the user menu would be beneficial to HTML applications. This could be implemented in a MENU set of HTML language. These MENU tags are not related to the original MENU and LI tags, which basically gives a bullet list (if my memory serves me correctly). Instead these would either yeild a programmable menu line inside the viewer window or actually alter the MOSAIC user menu bar. Thus one has the branch factor of an Event driven application.
The menu items would either be distinguished URLs to allow functionality differences for each FORM submittal or set a common variable to distinguish functional processing by the single URL associated with the fill-out FORM.
The following items would need to be implemented in HTML
206 Ridge Brook Trail NW
Duluth, GA 30136 USA
(404) 662-0997
Robert enjoys time with his wife, Susanne. They expect an addition to the family sometime in the VERY near future (Jerimy Daniel). Robert and Susanne met in Naples Florida on Christmas Day. Robert grew up in Naples. Susanne grew up in Germany (Wuppertal). Robert, Susanne, and Jerimy plan to move (return) to Germany in the next few years.
You can contact Robert Thralls at the followning E-mail address:
CDC WONDER