IBM WebSphere Developer Technical Journal: Jumpstart your WebSphere Host Access Transformation Services (HATS) Web project

Guidance and tips for transforming host applications for the Web

IBM® WebSphere® Host Access Transformation Services (HATS) provides a toolkit and a runtime for re-facing both 3270 and 5250 host applications for the Web using the IBM Software Development Platform. This article offers practical guidance, best practices, and tips for using the Web customization and transformation features of HATS in areas where users typically need a helping hand. These how-tos can help you simplify and accelerate your HATS V6 and V7 Web projects, and are appropriate for both novice and intermediate HATS developers.

William Flynn (wdflynn@us.ibm.com), Consultant, Host Access Transformation Services, IBM India Software Lab Services and Solutions

William (Bill) Flynn is a HATS consultant who has been working in Host Integration for the last 4 of his 25 years with IBM. Bill has a Masters degree in Computer Science from California Statue University Chico.



Sherri Midyette (smidyett@us.ibm.com), Senior Software Engineer, Host Access Transformation Services, IBM India Software Lab Services and Solutions

Sherri Midyette is a senior software engineer and has worked on Host Integration products in Research Triangle Park, North Carolina for 12 years. She has been chief programmer for two Host Integration product releases, as well as for the Host Integration componentization initiative. Sherri graduated from NC State University with a B.S. in Computer Science.



04 April 2007

From the IBM WebSphere Developer Technical Journal.

Introduction

IBM WebSphere Host Access Transformation Services (HATS) helps you create an easy-to-use graphical user interface (GUI) for your character-based 3270 and 5250 host applications. The features included with the HATS toolkit enables you to not only customize the user interface of a mainframe application, but improve its navigation as well. The toolkit's iterative development environment lets you customize elements of your host application gradually, as you develop and expand your expertise with the HATS toolkit and its capabilities.

Using examples, this article will explain how you can transform your host application into a custom Web application, with some tips to help you quickly achieve the screen transformation you want. This article describes:

  • Typical modifications you might want to make to the default transformation for your host application.
  • Tips for using selected HATS widgets.
  • Considerations for specifying reliable screen recognition definitions.
  • Tips for using the HATS Page Designer function.
  • Options for using multiple rendering sets to minimize customization of individual host screens.

Since this article focuses on providing tips for screen transformations rather than on being a step by step guide, some general knowledge of HATS and screen transformation is assumed. See the HATS User's and Administrator's Guide and the HATS Programmer's Guide (included with the HATS software), as well as the Resources below for more information.

In addition, this article focuses on building HATS Web projects, as opposed to HATS rich client projects (introduced in HATS V7). Many of the features contained here will also apply to HATS rich client projects, but the wizards and selections could be different for building a rich client project.


Tuning the HATS default transformation

If you're new to HATS, it's a good idea to begin your HATS Web project using default rendering, a convenient feature that maps host components to Web widgets (precoded, common Web application elements). Default rendering offers a reasonable Web presentation of a host application by mapping function keys and selection lists to Web links, and displaying the host fields without change. The result is a Web application that looks very similar to your original host terminal screen. This is a good beginning, but you will soon want to explore the HATS transformation capability so you can tailor your application screens based on the user's role, make the application's aesthetics align more closely with the look and feel of a Web application, and streamline the navigation of your host application to provide new efficiencies for your users.

But first things first. Let's take a look at the rendering set that HATS uses for transformations by default.

HATS is shipped with a default rendering set that will be applied to any "unrecognized" screen in your HATS application. Default rendering is important in that it provides your host screens with a consistent look and feel without requiring you to manually customize each screen. The default rendering set can be configured and customized for your specific host applications.

The appearance of screens rendered using the default rendering set is affected by more than just the rendering set itself. These settings, which include the default rendering set and are collectively referred to as the default transformation, affect all screens in your application and include these elements:

  • The template
  • The style sheet(s)
  • Global rules
  • Text replacement
  • Host keypad
  • Application keypad

It is important to know how and when to modify the configuration of these functions to adjust the look and feel of your default transformation. The next sections will look at making configuration changes to your default rendering set, your template, and your style sheets. Topics include:

The rendering set

In HATS, the default rendering set is configurable from the Rendering tab of the Project Settings section (Figure 1).

Figure 1. Rendering tab for project settings
Figure 1. Rendering tab for project settings

The ENPTUI items and subfiles are 5250 host components and will appear in the rendering set if you specified a 5250 host type, and if you selected Add ENPTUI support when creating your project.

You will need to tune the default rendering set if:

  • HATS is not recognizing particular host components on your host screens, or
  • HATS is not using the widget you want to use to render the host component, or
  • You do not need a special rendering of selection lists and function keys because you are fine with transforming these with the field widget.

When editing the default rendering, deselect any items in the list that you don't want to use, rather than removing them. The end result is the same, but you will be able to re-select the item again if the requirements change.

Next, some examples to illustrate customizing of the default rendering set.

Modifying the default rendering set

When a host component in your default rendering set (such as a selection list, function key, or subfile) is not recognized, check the settings for the host component first to make sure they are configured to recognize all variations of the component used in your host application. For example, suppose you have a problem where none of your selection lists are being recognized by the default rendering set, and so they are not being rendered as links. Your host screen selection list looks something like this:

	202.  Option description for 202
	203.  Option description for 203
		*
		*
	213.  Option description for 213

	Option ...... ______

On this host screen, the user would enter a value for Option, such as 202 and press Enter. Rendering these items on the Web page as links will yield an easier and faster solution for the user, who can simply click the desired option instead of manually entering a value. The settings for a selection list in the default rendering set are shown in Figure 2.

Figure 2. Settings for selection list
Figure 2. Settings for selection list

Notice that the delimiter after the token (202) is defined as either a period followed by a space, or as a dash followed by a space. In the host screen, the delimiter is a space, followed by a period, followed by two spaces. To make sure that the selection lists are recognized, you must add the delimiter of a space, followed by a period, followed by two spaces: " . " to the delimeter field. You could also remove the two delimiters that are already provided, but simply adding a new delimiter is the better approach.

After you alter the definition of the delimiter (Figure 3), the selection list can then be detected on the host screen, and the selection list items will then rendered as links. You could change this in the rendering item, but it is better that you make this change back at the project selection list component; this way, you configure the defaults to better match the host application components you will be transforming.

Figure 3. Settings for selection list
Figure 3. Settings for selection list

When working with a change to the default rendering set (or any other transformation), you will need to generate a screen capture of a representative host screen. Screen captures are handy for working on your transformation offline.

Consider the following approach to generating screen captures:

  1. With an experienced host application end user, navigate through the application using the HATS terminal.

  2. Use the Host Screen Preview tab of the HATS terminal to determine whether the screen is transformed properly.

  3. Capture a screen every time you notice a screen that represents some host component that you want to make especially sure that it renders properly.

  4. With your collection of screen captures, you can work on the default rendering set offline until you are ready to test again with a live connection to the host.

  5. When you display a screen capture, the Preview tab lets you view how the default rendering set will interpret the host screen.

Modifying templates and style sheets

In addition to the settings in the default rendering set, the rendering of unrecognized screens is also affected by the template and the style sheet that is applied to the default rendering. The template is an HTML wrapper for your Web pages, and it specifies a style sheet that defines colors, fonts, and the overall look and feel of the rendered page. Managing the template and the style sheet enables you to fine tune the appearance of your application to meet your organization's standards for Web applications.

HATS provides a variety of sample templates and style sheets that can be modified for your use. When you modify one of the style sheets or templates shipped with HATS, copy that file into a new file specifically for your own use. This way the original HATS style sheets and templates will still be available for future use or reference.

Among the samples, there is a blank template to which you can add your own graphics and links. The template is a JavaServer™ Page (JSP) and can be modified the same as any other JSP. If you look at the source code view of any HATS template, you will see the following code, which indicates where in the template the HATS transformation and application keypad will be located:

<HATS:Transform skipBody="true">
    <P> Host screen transformation will be shown here </P>
 </HATS:Transform>
<HATS:ApplicationKeypad settings="layout:horizontal"/>

Let's now look at style sheets. To locate the style sheets in your project, navigate to the HATS Projects view, then select Web Content => Common => Stylesheets. One or more style sheets might be used within a template. Looking at the Source view of the template in Page Designer, you will see this code near the top that defines the style sheets to be used:

<LINK rel="stylesheet" 
href="../common/stylesheets/monochrometheme.css" 
type="text/css">
<LINK rel="stylesheet" 
href="../common/stylesheets/reverseVideoMono.css" 
type="text/css">

To see how HATS uses the style sheets, display the settings for the widget definition of your choice. To find these, select the Rendering tab in the Project Settings view, then select the Widgets folder, followed by any specific widget. Figure 4 shows the definition for the Drop-down widget.

Figure 4. Settings for drop-down
Figure 4. Settings for drop-down

Notice the several references to the style classes. You can see the actual definitions by opening the style sheet. Since you are developing a Web application, you can use all standard style sheet techniques. If you are running your HATS project on the server, you can determine the style sheet classes being used for different parts of the Web page by viewing the project source from your browser.

Figure 5 shows part of the Monochrome theme style sheet (monochrometheme.css) used by the Drop-down widget definition.

Figure 5. Monochrome theme style sheet
Figure 5. Monochrome theme style sheet

In the Drop-down widget, you can modify colors, font sizes, and a variety of other parameters to assist you in controlling the look and feel of the default transformation.

Using the style sheet to manage alignment

Let's look at an example of how you can manage text alignment with a style sheet. Suppose you have a HATS application that renders selection lists as links, but a new company policy for Web sites mandates that you must use buttons instead of links. Currently your rendering looks like Figure 6.

Figure 6. HATS default rendering
Figure 6. HATS default rendering

For your selection list items to be rendered as buttons, you must modify your default rendering set to specify that selection list items should now be rendered as buttons instead of links (Figure 7).

Figure 7. Edit a default rendering item
Figure 7. Edit a default rendering item

As a result, your new host screen rendering now looks like Figure 8.

Figure 8. Render as buttons
Figure 8. Render as buttons

The result is exactly what you wanted -- almost. The selection list items are indeed now rendered as buttons, but the caption text on each button is centered, making them appear misaligned. Browsers also often add padding spaces to the captions, giving the buttons varying lengths.

To change the text alignment, you must adjust the style sheet parameters that control the buttons on the page. To determine which parameters you need to change, take a look at the button definition in the default rendering shown in Figure 9.

Figure 9. Button settings
Figure 9. Button settings

Here, the button style class used by HATS is HATSBUTTON. You have a few options for editing the button style. In this case, if you want to change the button style when selection lists are rendered as buttons using default transformation, click the S button next to the Style input field (available in HATS V6.0.4 and later). Alternatively, you can change the button settings at the project level (if you want to change the default for all buttons in the project), or you can change the button settings for a particular button on a page. If you want to change the style for all buttons using a particular style sheet, you need to locate this definition in the style sheet to make adjustments. For our purposes, you will edit the style sheet.

In the monochrometheme.css style sheet, the definition is:

INPUT.HATSBUTTON {

}

There are currently no special settings for the button style, as indicated by the empty braces. To align the text to the left, change monochromeTheme.css as follows:

INPUT.HATSBUTTON {

	text-align: left;

}

The screen will now render as shown in Figure 10.

Figure 10. HATS default rendering with button alignment
Figure 10. HATS default rendering with button alignment

You may feel that the aligned characters appear too far to the left, making the buttons look unbalanced. If so, you can make another change to add padding to monochrometheme.css:

INPUT.HATSBUTTON {

	text-align: left;
	padding-left: 4;

}

The host screen rendering now appears as shown in Figure 11. If you are satisfied with the look of the buttons, no further changes are required since your HATS application is adhering to the new company policy. Otherwise, you can continue to customize the button style as you wish.

Figure 11. HATS default rendering with button text padding
Figure 11. HATS default rendering with button text padding

This style sheet modification example is a very simple one, but this should give you an idea of how to make such changes. There are many different HATS widgets and many different settings you can use in your style sheet to manage their look and feel in the default rendering set or any transformation. Simply edit the style sheet and include any standard style sheet settings. Experimenting with style sheets and templates is often the best way to learn, and the best way to achieve the appearance you want.

Using the field widget

The Field widget determines how HATS will render standard field components. Do not remove field component rendering from your default rendering set; instead, leave field component rendering as the last item in your default rendering set, since this is the widget that will render host components not already rendered by preceding mappings. Examine the settings of the Field widget in the default rendering set and make changes that best suit your host screens.

For example, these changes might be required:

  1. If screens with many input fields do not line up properly, change the alignment on the Field widget to one of the values below. When HATS creates an HTML representation of a host screen, HATS creates an HTML table and inserts items into each table cell:

    • In normal alignment, HATS creates a table cell for each host field on the page.
    • In word by word alignment, HATS create a table cell for each word of text.
    • In character by character alignment, HATS creates a table cell for each character of text.
  2. If you want to show any extended attributes on your Web page, such as reverse video, enable extended attributes on the Field widget and the Subfile widget.

Host screen cursor position-dependent functions

You might have host screens that feature context sensitive help; for example, your host application lets you place the cursor over a field on the screen and press the F1 to get a definition of that field. For HATS to support this, you can modify the Field widget definition to Allow positioning on protected text, as shown in Figure 12.

Figure 12. Field settings
Figure 12. Field settings

HATS V6.0.2 features another way to enable the cursor to be placed on protected text. This feature is an alternative to HTML anchor tags for allowing positioning on protected text and is significant because it enables cursor positioning on protected text without using links; if you tab through the input fields on a Web page, the tabs will stop on the input fields as well as each protected text item. With this feature, the natural order of the actual input fields is preserved, making this a preferred option if your users frequently navigate input fields by tabbing. (See the HATS V6.0.2 (or later) release notes for details.)

Using the style sheet to dynamically change the screen size

Some host applications are coded to dynamically change screen size; such a screen could change from a size of 24x80 (characters) to 27x132 and back. When this occurs using an emulator, the font size on the screen automatically changes so that the entire screen fits in the emulator window. But when this occurs using the HATS default rendering set to render the screen, the font size remains constant.

If you prefer that your Web page behaves like the emulator and automatically change when using the HATS default rendering set, you need to create a style sheet for the new screen size, and then use this new style sheet when you detect a screen size change. Launch an existing style sheet in edit mode as a template, make your changes, and then save it with the new style sheet name.

Let's look at an example that changes the font size. Below is the beginning of the original whitetheme.css style sheet, in which you can see that the font size is set to 10pt:

BODY {
	background-color: white;
	color: black;
	font-family: sans-serif, arial, tahoma, helvetica;
	/* For accessibility compliance: remove the following line */
	font-size: 10pt;
}

TD, P, INPUT, A, TH, SELECT {
	font-family: sans-serif, arial, tahoma, helvetica;
	/* For accessibility compliance: remove the following line */
	font-size: 10pt;
}

Below is the start of the whitetheme_27X132.css style sheet, in which the font size was simply changed from 10pt to 9pt. Based on the emulator you use and your screen resolution, you might want to experiment with different font sizes to find the one that works best.

BODY {
	background-color: white;
	color: black;
	font-family: sans-serif, arial, tahoma, helvetica;
	font-size: 9pt;
}

TD, P, INPUT {
	font-family: sans-serif, arial, tahoma, helvetica;
	font-size: 9pt;
}

What about selecting a style sheet based on screen size? In a template, the style sheets are specified like this:

<LINK rel="stylesheet" 
href="../common/stylesheets/whitetheme.css" 
type="text/css">

To specify a style sheet to be used depending on the current screen size, you can add this code to the template:

<%
// begin
TransformInfo tInfo = 
((TransformInfo)request.getAttribute(CommonConstants.REQ_TRANSFORMINFO));
// Obtain the number of columns in the host screen.

HostScreen hScreen = tInfo.getHostScreen();

int length =0;

If (hScreen != NULL)
 length = hScreen.getSizeCols();

// Link to the proper style sheet based on the number of columns

if (length<132)

{
%>

<LINK rel="stylesheet" href="../common/stylesheets/whitetheme.css" 
type="text/css">
<%}
else
{
%>
<LINK rel="stylesheet" href="../common/stylesheets/whitetheme_27x132.css" type="text/css">
<%}
// end
%>

The template now determines the number of columns on the original host screen. If there are less then 132 columns, whitetheme.css is used, and if there are 132 columns, whitetheme_27x132.css is used. You now have the ability to vary style sheet settings based on the screen size. You can apply this simple concept to use multiple style sheets based on other similar conditions.


Using multiple rendering sets

In addition to the default rendering set that is shipped with HATS, you can create additional rendering sets to be used throughout your HATS application. Using multiple rendering sets is advantageous if you have some screens that require a common transformation and other groups of screens that require a different transformation. You don't necessarily want to create screen recognition criteria for every screen in a group and apply the rendering set to each one (although you can). Instead, it's better to find a way to specify that a particular rendering set should be applied to multiple screens without having to define unique screen recognition characteristics for each individual screen.

Before we look at two ways you can do this, let's review how to create a rendering set:

  1. From the HATS Projects view, select Project Settings, then click the Rendering tab.

  2. To add a new rendering set, select the Add button near the top of the screen to display the Add Rendering Set window.

  3. Name your rendering set and specify that you want to Copy new rendering set from existing set to populate the new rendering set with the items listed in the main rendering set. Figure 13 shows the new rendering set, CICS-renderingset, after it has been created.

Figure 13. Multiple rendering sets
Figure 13. Multiple rendering sets

Applying a rendering set to a group of screens with common recognition criteria

In this example, a new rendering set will be applied to multiple screens that have common screen recognition criteria. In addition to applying the rendering set, you will also add a new button to these pages.

Let's assume that there are several screens in your host application, all of which contain a title that begins with the word "File." The title appears in the same location on each screen, as illustrated in Figures 14 and 15.

Figure 14. Main terminal -- File add
Figure 14. Main terminal -- File add
Figure 15. Main terminal -- File update
Figure 15. Main terminal -- File update

You need to apply the new rendering set, CICS-renderingset, to all the "File" screens. As an additional requirement, you will also customize the rendering set to disable the foreground colors to give the screen a less distracting appearance:

  1. Edit the rendering item in CICS-renderingset that transforms field text.

  2. On the settings for the field widget, deselect Use project defaults and Enable foreground colors. You now have a unique rendering set with no foreground colors that can be applied to several screens.

Now, suppose you want to:

  • Apply your rendering set to the "File" screens -- but only up to line 12.
  • Replace the line 13 instructional text on all the "File" screens, such as "CHANGE FIELDS AND PRESS ENTER," with a Submit button.
  • Also apply CICS-renderingset to other screens in your application that do not require text replacement at line 13 with a Submit button.

To accomplish this, you will need to create a screen customization and transformation to apply to the "File" screens:

  1. Create a screen customization called CICSFiles and specify the recognition criteria for the screen by roping off the word FILE in the selected rectangular region, shown in Figure 16, then press Next.

    Figure 16. Create a Screen Customization -- CICSFiles
    Figure 16. Create a Screen Customization -- CICSFiles
  2. On the Select Actions page of the Create a Screen Customization wizard, name the transformation: CICSFiles. Specify /Blank for Rendering Options, then select Finish. Your blank page should now be viewable on the Design tab of the Page Designer.

  3. From the toolbar, select HATS Tools => Insert Default Rendering. This selection will enable you to choose from all rendering sets you have defined in this project. Figure 17 shows how to select the rendering set you want to apply and where to apply it on the screen. For this example, you want to select CICS-renderingset and only apply it to the first 11 lines of the File screens.

    Figure 17. Insert Default Rendering
    Figure 17. Insert Default Rendering
  4. After you click Finish, use the mouse to select where you want the rendering set inserted on your page. The Design tab page will show the host screen you are using for this transformation with the CICS-renderingset applied.

  5. You are now ready to add the Submit button to this transformation. Since you indicated that the rendering set was only to be applied to the first 11 lines on the screen, you can now simply add a Submit button. Select the Form Tags folder from the Palette (Figure 18). Select where you want to place the button on the page and define it. You have now completed the definition of your transformation.

    Figure 18. Design view -- File add
    Figure 18. Design view -- File add
  6. To view the Source of the screen customization, select the Source tab to verify that you have applied the correct rendering set to the first 11 lines of the page and that the Submit button was added as planned (Figure 19).

    Figure 19. Source view
    Figure 19. Source view

Figure 20 shows the File Update screen with your screen customization and transformation applied. The screen also reflects your change to CICS-renderingset to disable foreground colors, and shows the new Submit button.

Figure 20. File update screen
Figure 20. File update screen

If you wish, you can use this same technique to apply any rendering set to any individual screen. In that case, you will need to create screen recognition criteria that will recognize a single screen in your host application.

Applying a different rendering set to each application accessible from a common host screen

In this next example, your host is accessed by a logon screen where your users can specify an application of either CICS or TSO (Figure 21).

Figure 21. Host terminal -- Logon
Figure 21. Host terminal -- Logon

The layout of the CICS screens are similar as a group, and the layout of the TSO screens are similar as a group, but the layouts of the two groups are different and, therefore, require different rendering sets to apply to each application.

You will need to create two new rendering sets, one for the CICS application and one for the TSO application. This section will show how you can set up this scenario for the CICS screens, then you can simply repeat the same procedure for the TSO screens.

You can reuse CICS-renderingset from the previous example the CICS screens. Since you want to apply this rendering set to only the CICS screens, you need to determine: What describes a CICS screen? There are no common recognition criteria for all CICS screens, but you can create recognition criteria for the first CICS screen that is always encountered after launching CICS, then use a global variable to help HATS know when to apply CICS-renderingset.

Suppose your screen flow has a main screen from which you can navigate to either the CICS or TSO application, as in the flow shown in Figure 22.

Figure 22. Screen flow
Figure 22. Screen flow

Set a global variable to CICS when the user navigates from the main screen to the CICS application. When the user continues on to successive CICS screens, the global variable will remain set to CICS. Therefore, whenever the global variable is set to CICS, you can apply the transformation specifically for CICS screens.

Likewise, you will also set a global variable when the user navigates from the main screen to a TSO application. The global variable will remain set to TSO so long as the user is navigating through TSO screens:

  1. For the main screen, define how to transform that screen and set the global variable to indicate that the screen is neither a CICS nor TSO screen.

  2. Create a transformation for the first CICS screen that is encountered in the screen sequence. Use the Insert Default Rendering technique described in the previous example to specify that the CICS-renderingset will be applied in this transformation. Name the transformation with a term that encompasses all CICS screens, such as CICSScreens.

  3. Next, create a customization for this CICS screen. For this customization, specify recognition criteria as you normally would. Then, on the Actions tab, set a global variable to CICS and apply the CICSScreens transformation you created, as in Figure 23.

    Figure 23. Action list
    Figure 23. Action list
  4. You have completed the rendering of the first CICS screen and have a global variable that tells HATS that the user has entered the CICS application. After entering the CICS application screens, though, you want HATS to apply the CICS-renderingset to any unrecognized screen. To do this, you will need to create another screen customization that applies to all the CICS screens except the first one. Specify your recognition criteria as matching your screen if the global variable is set to CICS (Figure 24) because you know the global variable was already set when the first CICS screen was recognized.

    Figure 24. Global variable criterion
    Figure 24. Global variable criterion
  5. This screen is for customizing all CICS screens. As your Action, specify that you want to apply the CICSScreens transformation. This indicates that your CICS screens will be displayed using your CICS-renderingset.

  6. You would need to follow these same steps to identify a unique rendering set for your TSO host screens.

    You probably don't want to apply your CICS or TSO rendering sets to the main screen, on which you specify your logon information and either CICS or TSO as your application. Instead, you will want to create a screen transformation or, perhaps, use default transformation for the main screen.

  7. After you have created the screen transformation, select Project Settings and then the Event tab (Figure 25). Move the MainScreen customization to the top of the Screen Customization Priority list, so that when the user of your application backs out of either the initial CICS or TSO screen, the main screen will be recognized.

    Figure 25. Screen Customization Priority
    Figure 25. Screen Customization Priority

You have now applied your two new rendering sets to different applications accessible from one main screen. You did not need to create screen customizations unique to each panel in the application, or even determine screen recognition elements to apply to groups of CICS screens. Instead, you used HATS global variables to determine the state of your host application, and to determine when to apply your multiple rendering sets.


Advanced widgets

You can make your users more productive and give your transformed application a professional GUI Web look by using advanced, precoded elements, or widgets, such as the calendar, tabbed folder, graphics, and checkbox widgets.

Calendar widget

The Calendar widget provides a graphic calendar that enables a user to select a date instead of manually entering it. When you use the Calendar widget, a servlet is invoked by HATS to render the content. If you use Page Designer, the Calendar widget will not render properly in the Preview view. You will need to use the Run on Server option and set your Web browser with your projects to an external Web browser. Select Window => Preferences => Internet => Web Browser to add the browser of your choice. It is best to render your projects using an external Web browser to see how your screen rendering will look to users.

Figure 26. Calendar widget
Figure 26. Calendar widget

Checkbox widget

Use the Checkbox widget for rendering an input field with an item selection. With the Checkbox widget, you have an input field component which can have one of two values, one (default) value checked, the other unchecked (Figure 27).

Figure 27. Check box settings
Figure 27. Check box settings

You can also display a list of possible values without visually showing a default value by inserting data in the host screen so that you have an initial value for the checkbox.

  1. Select your Screen Customization, then the Actions tab, and then select to Add an action.

  2. Select Insert data at the location of the applicable input field on the host screen, then enter the value you want, like 2.

  3. Finally, move the Insert data action to be run before the Apply a Transformation action. Now when you run your application, your host screen will show an unchecked selection, yet have the value of 2 mapping to the unchecked box, as shown in Figure 28.

Figure 28. Checkbox rendering
Figure 28. Checkbox rendering

Tabbed folders and graphs

Design your new Web page so that it contains only necessary user information. Dure to the nature of the display, it is typical for many host screens to contain more data than is usually necessary, making it difficult to manage on one page. If possible, find a way to split the data from busy host screens to across multiple Web pages. One common method for doing this invloves simply providing new, consecutive Web pages, each showing a portion of the data. Another intuitive way to handle this, illustrated in the example here, is to use tabbed folders to display the host screen data at once across selectable tabbed folders. Look at the cluttered host screen in Figure 29.

Figure 29. Cluttered host screen
Figure 29. Cluttered host screen

This may look like a typical green screen application screen, but closer analysis reveals that this screen is a bit busy and complicated -- but more importantly, the information that users need from this screen is primarily that which is located in the top left column. Although a user may occasionally need another data item that is displayed here, the bulk of this data tends to merely be a distraction.

Using a HATS tabbed folder, the main information that users need could be rendered as in Figure 30, on the Main System Status tab.

Figure 30. Main System Status tab
Figure 30. Main System Status tab

A second tab, Complete System Status (Figure 31), could render the complete data on a single page for those rare times when all the data is needed at once. Screen data rendered in each tabbed folder does not need to be mutually exclusive; you can certainly duplicate data across tabs, depending on your requirements.

Figure 31. Complete System Status tab
Figure 31. Complete System Status tab

Our next example shows how you can use multiple graphs to display the same screen data. Figure 32 shows a larger portion of the system status data in a textual format, which an experienced host screen user might prefer to see.

Figure 32. System Status tab
Figure 32. System Status tab

The second tab, Pool Data H (Figure 33), shows that same data as a horizontal bar graph for those users who prefer something visual.

Figure 33. Pool Data H tab
Figure 33. Pool Data H tab

A third tab, Pool Data V (Figure 34), shows the same data again, rendered this time with a vertical bar graph, illustrating that you can use different graphs to show the same data, depending on the preferences of your users.

Figure 34. Pool Data V tab
Figure 34. Pool Data V tab

To create a tabbed folder in a HATS transformation, select HATS Tools from the menu bar and then select Insert Tabbed Folder. When you create a tabbed folder, HATS gives you the option to set the tab height, folder height, and folder width. These values are in pixels and are set in the main tabbed folder definition screen (Figure 35).

Figure 35. Insert Tabbed Folder
Figure 35. Insert Tabbed Folder

After you have inserted the host components into each tab of the tabbed folder and have inserted the tabbed folder into your screen transformation, you might want to adjust some values, which you can do in the source code. For example:

  1. In the Source view of the Page Designer, look for the tabbed folder; more specifically, for this line:

    var Tabhatsportletid1162407643234TabbedFolder = new TabbedFolder('Tabhatsportletid1
    162407643234','0','12','30',Tabhatsportletid1162407643234Array,Tabhatsportletid1162
    407643234CSSFamily,'400','400');

    The first "400" in this line is the folder width in pixels, the second is the folder height. You can adjust the width of the tabs so that the tab headers are easier to read. HATS will automatically set each tab width based on the length of the header. But you can override this behavior in the source code.

  2. For each tab header, this line will display in the Source view of the Page Designer:

    style="z-index:2;"

    The number "2" represents the order number of the tab. Add a width parameter to the tab style as follows:

    style="z-index:2;width:200;"

Defining reliable screen recognition criteria

Since screen recognition is used for creating screen customizations and macros, defining screen recognition criteria is a critical step in making sure HATS renders your host application as you expect.

When defining screen recognition for a customization, you must take your entire host application into consideration. HATS will check each screen in the host application to see if the screen matches the screen recognition criteria for your customizations. It is imperative to make sure that your screen recognition criteria uniquely defines the screen or screens where you want your customization applied.

For all screen recognitions, HATS uses the philosophy of "first fit" as opposed to "best fit"; screens are checked in the order that they are defined. In the case of screen customization events, the Screen Customization Priority list is checked in the order specified. In the case of macros, the next screens are checked in the order that they are defined.

Making your screen recognition criteria flexible

When defining your screen recognition criteria, make your recognition as flexible as possible without compromising the unique definition for your screen or screens. Be careful not to use variable data in your screen recognition criteria; this is a common error that may seem obvious, but is often difficult to track, since it can seem that a screen which had been consistently recognized is suddenly not recognized when, for example, the date changes. An example is shown in Figure 36.

Figure 36. Host terminal -- Main menu 2
Figure 36. Host terminal -- Main menu 2

To recognize this screen, you might just specify to check for the text "i5/OS Main Menu" anywhere on the screen, assuming you are confident that no other screen in the host application has this text as a title. (Make it a practice to always confirm such assumptions with the host programmers or with experienced end users.)

If the text is not unique to this host screen, try checking for "i5/OS Main Menu" text within a specific region on the screen. Being able to recognize this criteria without having to check for the text in a specific position makes your screen recognition criteria more flexible, should the position of the text even change slightly in location.

Figure 37. Create a screen customization
Figure 37. Create a screen customization

The nature of traditional host applications is such that shifting a screen label left or right a few characters might not be considered significant. The end user might not notice, but your screen recognition could stop working if you have created a criterion that is not flexible enough to account for such a change.

Screen recognition options, like Total number of fields, Total number of input fields, and Cursor position, can be used when you need to be very specific in recognizing a single screen. These options are not recommended as a general practice, since these types of indicators can change more readily.

Making your screen recognition criteria unique

Let's take a look at two screens that are similar.

The screen shown in Figure 38 is the one that displays under normal circumstances, when there is no host error. However, you have a requirement to run a different set of actions depending on whether the error-free condition is displayed, or if text indicating an error is on the screen. As such, your screen recognition criteria might look for "i5/OS Main Menu" to determine which main screen is being rendered, and then "COPYRIGHT IBM CORP" from the bottom of the screen to verify that you are in an error-free condition. Let's call this customization "Main Menu Good."

Figure 38. Main Menu Good
Figure 38. Main Menu Good

Figure 39 shows this same host screen with an error condition: "Not authorized to change user profile" is displayed on the bottom of the screen. This will be Main "Menu Error."

Figure 39. Main menu error
Figure 39. Main menu error

Without being interested in the specific error message, your screen recognition might simply check for "i5/OS Main Menu" at the top. But this recognition criterion does not uniquely define this screen, since Main Menu Good will match this same recognition criterion. For this to work, you must make sure that HATS checks for both customizations -- but in a particular order. If HATS uses the following order:

  1. Main Menu Error
  2. Main Menu Good

the customization Main Menu Good will never be recognized, since the customization Main Menu Error is only checking for the top screen title i5/OS Main Menu, which is a match for both screens. But using the correct sequence:

  1. Main Menu Good
  2. Main Menu Error

filters both screens so that all the "good" screens are identified first, then the screens that are "bad" are identified as a subset.

You set this sequence in HATS by selecting the Project Settings, then the Events tab. The Screen Customization Priority list is shown in Figure 40.

Figure 40. Screen customization priority
Figure 40. Screen customization priority

Simply move each screen customization up or down in the list to achieve the required identification sequence for screens that are essentially similar.

Getting optimal performance from your screen recognition

When you run your HATS application, HATS checks each new host screen to see if the screen matches any of your customizations, in the order you have specified. If you have a large number of customizations in your project, the performance of your HATS application could be impacted. For the sake of efficiency, place your most often used screen customizations at the top of the customization order list, since the search for a screen match stops once a match is found. You should place your most specific screen recognition criteria higher in the list as well.

To further refine your search, you can define the probable next screens within a screen customization so that HATS will check for those screens first after recognizing any screen that matches your criteria in the customization (select the Next Screens tab, shown in Figure 41).

Figure 41. Next screens
Figure 41. Next screens

HATS uses this ordered list of screens to check for matches before using the entire list of ordered customizations defined in the HATS project. You can also define a specific action to take if one of your probable next screens does not appear.

Using screen recognition in macros

For screen recognition in macros, follow the same general guidelines discussed throughout this article, but with one additional consideration for next-screen order.

Macros are structures that navigate a sequence of recorded screens by processing the recorded keystrokes of the developer. Macros identify a starting screen, run actions on that screen, and then wait for one of several possible next screens. Once a next-screen is received, actions are run on that screen, and the macro then looks for the next screen. This process continues until the macro ends.

At each point where the macro is waiting for its next screen, HATS again uses a "first fit" policy, as opposed to a "best fit" policy. If your macro has a point where there is more than one possibility for the next screen (that is, you have recorded your macro with multiple paths), then the order of those next screens might be important for screen recognition considerations. For macros, this works similar to screen customizations.

Look at the AccountBalance macro in Figure 42. The next screens for the Operator Instructions screen are "FileInquiry" and "OperatorInstructionsError." Based on the macro's recording, HATS will check first to see if it recognizes the next screen as FileInquiry before checking to see if it is OperatorInstructionsError.

Figure 42. Host terminal -- sign on
Figure 42. Host terminal -- sign on

Assume the two next screens are similar so that the FileInquiry screen can recognize them both, but that the OperatorInstructionsError screen has specific recognition criteria that only OperatorInstructionsError will match.

To change the search order of the next screens, right click on Next Screens for the screen Operator Instructions. The dialog that displays (Figure 43) will enable you to add, remove, and modify the order of the next screens. You can also change the next screen order from the advanced macro editor.

Figure 43. Edit next screens
Figure 43. Edit next screens

Using HATS components with Page Designer

Page Designer, part of the IBM Rational® Software Development Platform, enables you to create and design Web pages by providing a Design view from which you can select Web components (images, links, buttons, and so on) to drag and drop on the canvas, a Source view if you need to modify code, and a Preview view to display the rendering of your Web page. The HATS toolkit is integrated with Page Designer so that you can use HATS components in your Design view like any other Web component.

To add a HATS component, either drag and drop a component from the HATS palette or use HATS Tools, from either the menu or by right clicking on the Design view and selecting Add a HATS component. Here are a few pointers for using the Page Designer with the HATS components.

Prepopulate will not include empty fields

When creating a HATS screen transformation, you have the rendering options of Blank or Prepopulated. The Prepopulated option is used to seed your Web page with component tags generated by the project default rendering. You can use this option on a screen where you want to start with the default rendering, and then modify components and widgets to get the transformation that you want. If your host screen has a field that does not contain a value (such as a status line that does not contain a status), the field will not be prepopulated for display.

In Figure 44, the status line of the host application shares the bottom line of the screen with the copyright.

Figure 44. Design view -- Sign on
Figure 44. Design view -- Sign on

If you use this transformation, when you take an action on your host application that causes status text to appear on the host, the Web page will not show the status because you have not defined the entire region that contains the status as a field component. Figure 45 shows the host screen when the status appears on the bottom line without the copyright text.

Figure 45. Host screen with informational status
Figure 45. Host screen with informational status

To correct your Web page, use the Design view to stretch the field component over the entire area where the status could appear. In this example, you could stretch the field component containing the copyright to span to the left edge of your Web page, as shown in Figure 46. This enables the text to be displayed across the entire line.

Figure 46. Design view -- Sign on with copyright text
Figure 46. Design view -- Sign on with copyright text

Additionally, the field component must be set to retrieve the entire row where the text can appear. Edit the field component so the selection spans columns 1 through 80. Now, either your status line or your copyright will appear as the host application developer intended.

In general, when prepopulating your Web page, use a screen capture that contains as much of the information you want to render as possible. This way, rendering tags will be generated for all or most of the host components on the host page, requiring you to do little or no work to add any missing host components. For example, if you use a screen capture showing only a partial table and then run the application when a full table is displayed, only the portion of your table for which tags were created (the portion displayed in your captured screen) will be rendered.

With HATS V7, there is a new setting that enables you to include empty fields when a prepopulated transformation is created.

Placing HATS components in the Design view

If you use the HATS Tools menu to insert HATS components, you will not automatically see your component added to the Design view. After you define your HATS component and select Finish, your cursor will change to a cross hair, indicating that you should rope the rectangular region where you want your HATS component inserted on the page.

If you use the HATS Component palette in the Palette view, you should click once on the HATS component you want to add, then click once on the cell in the Design view where you want the HATS component located. After defining your HATS component, you can resize your chosen cell.


Conclusion

This article described several best practices and tips to help you develop your HATS application more quickly and efficiently. If you take care in customizing your default transformation, your entire application will benefit from a more cohesive look, plus you will reduce the customization necessary for individual screens. With multiple rendering sets, you can further reduce the number of individual screens you need to customize by applying additional rendering sets to groups of screens. Screen recognition is a key part of making your HATS applications display and perform as expected. Make your recognition criteria unique but flexible. Use Page Designer to prepopulate any screen you want to customize, and then make specific changes to the screen layout. Finally, take care in specifying host component and widget settings for your particular host application. The HATS out of the box default transformation is nice for many host screens, but to get the Web customization you prefer, you will likely need to modify your settings.

If you follow these guidelines, you will be able to reduce the work required to build your HATS project and achieve the desired look for your new Web application.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Rational
ArticleID=206141
ArticleTitle=IBM WebSphere Developer Technical Journal: Jumpstart your WebSphere Host Access Transformation Services (HATS) Web project
publish-date=04042007