Questions

• How do I create a link to the Screensurfer Web Gateway "home" page?
  
• How do I change the appearance of the "home" screen?
  
• How do I change the default appearance of pass-through screens?
  
• When I make template changes, how do I activate (recompile) them?
  
• How do I identify a specific screen to Screensurfer?
  
• How do I add a link to a displayed screen page?
  
• Can I execute SurferScript based on a specific link (URL)?
  
• Can I validate user entries?
  
• Can I restrict which screens a user can see?
  
• How can I re-format a screen to be more readable?
  
• How do you include screen data mixed with static HTML?
  
• What is the best way to re-format multiple screen rows?
  

Questions and Answers

The Web Gateway home page is displayed whenever the web gateway port for Screensurfer is accessed without a resource in the URL, or a resource of "/home" in the URL. Therefore, to access Screensurfer on the same machine, enter a URL of HTTP://127.0.0.1:port where port is the HTTP port you specified during installation for the web gateway.
When you installed Screensurfer, you specified the HTTP Port for the web gateway. The default port is 80, which is the standard HTTP port for web servers.
If you are using the Developer's License for Screensurfer, you can only access the web gateway port from the same machine. If you have a Live Server or Elite Server license, you can access Screensurfer from any machine addressable using IP protocols. In this case, you simply point to the Screensurfer machine in your URL to access the Web Gateway. For example: HTTP://surferguy (the Screensurfer machine has a network name of "surferguy" and the default HTTP port of 80 was selected during installation.

Edit the file global.stml in the active templates folder-- a link to this folder is provided in the Screensurfer folder created during installation.
In global.stml is a tag <TESECTION Home>, which identifies the HTML used to present the Screensurfer home page. You can make any changes to this section you wish, recompile and they will take effect the next time the home page is loaded.

Edit the file global.stml in the active templates folder-- a link to this folder is provided in the Screensurfer folder created during installation.
In global.stml is a tag <TESECTION Default>, which identifies the HTML used to present any unrecognized screen (the global.default section). You can make any changes to this file you wish, recompile and they will take effect the next time the home page is loaded.

NOTE: Development activities with Screensurfer require your browser to be at version 4 of either Netscape or Microsoft Internet Explorer, as the level of JavaScript used in the DevCenter requires these versions.

From either the Screensurfer folder or the Start/Screensurfer menu, select the DevCenter item. This will load the DevCenter. In the upper left frame of the DevCenter is a link Administration; click on this. On the next menu in the same frame you will see a link for Recompile Templates; click on this, and a compiler output report will appear in the primary frame.
If the DevCenter selection displays an error such as "No reply from server", make sure that the Screensurfer service is started, by using the Service Control selection from either the Screensurfer folder or the Start/Screensurfer menu.

You identify screens using the <TESECTION> tag inside one of your template files. You can create a new template file (template files are standard ASCII HTML files) or add the section to an existing file. In the <TESECTION> tag is an optional attribute of WHEN Screen_row_column IS "text" which the Screensurfer compiler reads and inserts into the screen recognition rulebase. You can combine multiple tests with an AND token.

Example:


  <TESECTION MyScreen WHEN Screen_1_2 IS "SALES02"
	              AND Screen_1_60 IS "DETAIL">

Following compilation, whenever a screen is displayed which matches the criteria in your when clause, the HTML and SurferScript between the <TESECTION> tag and the next </TESECTION> or next <TESECTION> will be executed/displayed in the next HTML page.
You should organize your screens so that related screens for a particular part of your application are in the same template file-- this way, it is easy to manage related variables, as well as divide work between more than one developer.

Once you have identified a screen (see above question), the SurferScript that displays that screen can include any HTML link you wish. For example, the following will display the top ten lines of a screen, then display the next line, making the line a link that enters the command "CUSTINQ" in the current screen. Each tag used in the example is summarized below:

<TESECTION MyScreen WHEN Screen_1_2 IS "MENU1">
<TEAREA 1 1 10 80>
<A HREF="<TEMACRO SENDKEYS
    '[home][erase eof]CUSTINQ[enter]'>">
<TEAREA 11 1 11 80></A>
<TEAREA 12 1 24 80>
</TESECTION>


Tag Summary


• <TEAREA> Displays an area of the active screen
• <TEMACRO SENDKEYS> Creates a URL that will link-back to the user's session (with identification and authentication) and enter the provided keystrokes.

Yes. To define sections of HTML that execute based on a URL, you use the WHEN TRANPATH_n clause of the <TESECTION> tag.
This allows you to define a URL that has one or more parts separated by forward slashes. To assure compatibility with future implementations that route requests through web servers such as Netscape or Microsoft Internet Information Server, all Screensurfer URL's start with "/Surfer/".
So, a customer details request may include the URL of:
http://myserver/surfer/cust/details?Cust=Jones

The above URL will execute SurferScript that has the following <TESECTION> tag:

<TESECTION CUST_DETAILS WHEN
   TRANPATH_1 IS "cust" AND
   TRANPATH_2 IS "details">

Yes, there are a number of ways to achieve entry validation. The two primary ones with Screensurfer are JavaScript at the browser or a Web Event at the Screensurfer server.
You can incorporate and use JavaScript just as with any HTML form (the description of using JavaScript to validate user entries is beyond the scope of this document).
At the Screensurfer server, to check user input prior to entering in the host, you use the <TEEVENT WebInput> Tag, which defines a block of SurferScript to be executed when a user submits a page produced by the current screen's section.
You place the <TEEVENT> tag following a <TESECTION> tag, before the next </TESECTION> or <TESECTION> tag.
If the user entries are invalid, you can display a new page to the user simply by including HTML inside the <TEIF> tag that detected the error, then use the <TEACTION RETURN> tag to prevent host entry.

Yes. To do this, you should declare a user ID variable in one of your templates, using the <TEDECLARE VAR> tag. Then, on your logon screen, identify the web variable that contains the UserID and use the <TESET> tag to save the userid in your declared variable.
You can then use the ODBC support in Screensurfer to read a user profile with the userid as a key. In the user's profile can be security information, such as the group the user is a member of.
Once you have the information about the user stored in SurferScript variables, it is easy to use the <TEIF> tag to determine if the user is priviledged for a particular screen or a particular area of a screen.
Another global method of limiting the screens available with Screensurfer is to change the global.default SurferScript section to display an error message, such as "Sorry, this information is not available through our web page". Then, all the screens that are identified in their own <TESECTION> tags will be displayed, while any not authorized will simply display the error message (and perhaps disconnect the user if appropriate).

Many, many techniques can be utilized. In all cases, you will take what is used on the global.default section as a starting point, and break-up the screen into separate pieces which allow you to intermingle static HTML formatting text with the data on the screen. An excellent resource in any of these reformats is the DevCenter (accessable through the Screensurfer folder), which provides a number of wizards that can assist in rapidly breaking a screen up into individual components which are then easy to move around and edit in an HTML editor.
For a query display which has little or no data entry, try reorganizing the HTML page to exploit the virtual scrolling area of the web browser. Use HTML tables to better format the information, with color and font changes to identify certain data or exception conditions.
For a crowded data entry screen, a simple design which requires little effort is to reorganize all the fields on the screen into a two column HTML table. This way, all the prompts may be expanded into a more readable format.

In a section of SurferScript, you simply include HTML as straight text in the section. Any time you want to utilize data from the screen, the <TEAREA> tag and the <TEDATA> tag are both easy to use and will dynamically display screen data (and even automatically generated entry fields).
If you are setting text into a SurferScript variable and wish to include screen data, the Screen() Function may be used to dynamically read active screen data.

Use the <TELOOP> tag to execute SurferScript and HTML in a loop. This way, you can rapidly code using a row expression in all your <TEAREA> and <TEDATA> tags (as well as any decisions using the <TEIF> tag).
You can then preceed the loop with an HTML <TABLE> tag, making each iteration of the loop generate a row of the table.
For instances where more than one screen may display the same set of multiple rows, an "outer" <TELOOP> can check if there are "more" rows on subsequent screens, then use the <TEACTION ENTER> tag to scroll to the next screen.