But It Doesn't Look Like IC!

If I told you that this

Figure 1

was a Clarion Internet Connect app, you would believe me. It looks like a Clarion app (the live app is at http://www.par2.com/cws/c5launch.dll/coolfaqs.exe.0).

And, if I told you that

Figure 2

was also an Internet Connect app, again, you would believe me. You would believe me because you remember that this app was the subject of last month's look at HTML list boxes. What prima facie evidence is there that this is not a standard HTML Web page?

The app appears to feature a small <table> structure with several buttons, two string literals and a <Text> field. Below these there is a <select> structure and two more <table>s with navigation buttons. And, if you look at the HTML source, this is just what you will see; no applets, no scripts, just HTML. Maybe it isn't an IC app.

Of course it is an IC app, but because it uses Tony Goldstein's Caffeine-free template modifications (http://www.cwsuperpage.com/articles/cwicfaq/caffeinefreecwic.htm), if you run this app from a Java-disabled browser, it will run and run correctly. The most persuasive evidence, in fact the only evidence, appears if you examine the HTML source more closely. If you do, you will see:

<CENTER>
<FORM NAME="ClarionForm" METHOD=GET ACTION="/cws/cwlaunch.dll/NEWFAQS.EXE.1093533715"

(emphasis added) which gives it away (at least to those of us in the know).

Now, suppose I told you that

Figure 3

was an IC application. Would you believe me? Ignoring my obvious lack of proficiency with graphics, this could be almost any Web page. More to the point, would someone seeing it for the first time think that it was a standard Web page?

Well, in fact, it is a standard web page. But, instead of hand coding the HTML, I used a design tool to create it. The tool is not Frontpage, Dreamweaver, Cold Fusion, Web.Designer, Home Page or any similar product; it happens to be Clarion 5 Enterprise Edition (surely you realized this was coming).

The Underlying Logic

IC gives us additional embeds before and after each control and each major component in a window (caption, window area, etc.) for the express purpose of embedding internet specific code. Usually such code either is HTML or conditionally generates HTML. But, and this is the important part, the IC templates provide similar embeds for the Web page and its components. These embeds are important because they generate code into the parts of the Web page physically outside of the application's window.

An HTML page is structured as:

<html>
  <head>
    <title></title>
  </head>
  <body>
  </body>
</html>

Each has close counterparts in the Clarion language.

The "<html>" tag is exactly like the Clarion "Program" statement. It begins an HTML script. Similarly, "</html>" is just like the final "Return" or "ThisWindow.Kill" call, ending an HTML script.

The "<head>" section is very much like the module section. It is used to declare variables visible to the entire page, functions that can be called from anywhere within the page, etc. Like "Module," declarations here are not visible to other pages (in HTML this is called the "global" area).

Most importantly, "<body>" is almost exactly equivalent to the "Code" statement. It is with this statement that things start to happen Clarion code statements in an embed immediately after this statement, will execute before anything else, even before your setup code. "Before," that includes the critical "Open(window)" statement.

In Practice

If you were to create the bare bones HTML <table> structures required to duplicate Figure 3, it would look like this:

Figure 4

Note that I have marked where I want my Clarion window to display with the literal "page here."

Adding the graphics, it becomes:

Figure 5

The code generated is:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title></title>
</head>
<body bgcolor="#FFFFFF">
 First table creates a large, outer table
<table border="0" cellpadding="0" cellspacing="0" width="90%">
    <tr>
                         This creates a table to hold the top banner
       <td width="100%"><table border="0" cellpadding="0"
       cellspacing="0" width="100%">
           <tr>
               <td align="right" width="100%"><img
               src="Par2.gif" width="545" height="92"></td>
           </tr>
       </table>
       This creates a table for the side banner
       <table border="0" cellpadding="0" cellspacing="0"
       width="100%">
           <tr>
               <td> - this cell contains the side banner
               <td align="center" width="25%"><a
               href="http://www.cwicweb.com"><img src="Logo.gif"
               alt="CWICWeb" border="0" width="100" height="31"></a><hr>
               <p><font face="Arial Black">Clarion Web Ring:</font>
<a href="http://www.webring.org/cgi-bin/webring?ring=cwsuperring;list"><img
               src="CWSUPERRINGPREVIOUS.GIF"
               alt="Visit Previous ring site" border="0"
               width="104" height="30"></a><br><img
               src="CWSUPERRINGINDEX.GIF" alt="CWRing Index"
width="104" height="30"><a href="http://www.webring.org/cgi-bin/webring?ring=cwsuperring;home"
               target="_top"><img src="CWSuperRingLogoSmall.gif"
               alt="CWSuperRing Home Page" border="0"
width="104" height="30"></a><br><a href="http://www.webring.org/cgi-bin/webring?ring=cwsuperring;random"><img
               src="CWSuperRingRandom.gif"
               alt="Visit a randomly choosen CWRing site"
border="0" width="104" height="30"></a><br><a href="http://www.webring.org/cgi-bin/webring?ring=cwsuperring;lid=4;next"><img
               src="CWSUPERRINGNEXT.GIF"
               alt="Go to the next site in the ring" border="0"
               width="104" height="30"></a><br></p>
               </td>
               <td align="center" valign="top" width="75%">page
               here</td> This cell is where the app goes!
           </tr>
       </table>
       </td>
   </tr>
</table>
</body>
</html>

It is obvious that I do not need the first seven lines of this HTML (that is, everything before the first <table> declaration) because the IC templates will generate that for me. For the same reason, I do not need the last two lines of HTML. It is also obvious that my marker is extremely useful (that is, beyond reminding me what I want to do) as a cut-and-paste marker. Everything before it must go before opening the application window and everything after, must go after all Clarion code.

The question that remains is that eternal Clarion question, "Where?"

Implementation

For HTML to be visible, the <body> must be opened (i.e., the script must be read up to and including the <body> tag). That means that Clarion's Open(window) cannot occur before the <body> tag is opened to accomplish what we want. And, that means that immediately after opening <body> tag is where the first (and larger piece) of the HTML should go. Logically, the remaining HTML will go before closing the <body> tag. This way, all the HTML is entirely outside the Clarion window.

Figure 6

Except

If you do this, your <table>s will appear, but your images probably will not.

Your app and your images are not usually in the same directories when running IC. (If they are, your images did appear and you're wondering what the fuss is about.) The reason is that the HTML is no longer simply HTML, it is part of your Clarion app, dynamically generated into the completed page at runtime. Thus, you have to address your images in accordance with IC's requirements. Assuming your images are in your /public directory, you need to add "/" to your image references. For example:

<img src="/Logo.gif">

In short, any external object referred to in your skeletal HTML must conform to IC's calling requirements.

And what if your app is multiple pages and you want these <tables> on each? Do you have to copy these embeds to each and every page? Of course not. You could, but you do not have to.

If you modify your templates as Tony has shown us, you can use frames. This obviates the need to create any embeds at all. Of course, if part of your purpose is to make your application accessible to all browsers, you can't use frames as not all browsers support them.

You have several other options. You can create two separate files and Include() them at the appropriate places. In fact, you can use one file and place section titles (using the

INCLUDE(filename [,section])

syntax). This has the advantage of a single maintenance point and, further, that any changes you make are propagated by a simple re-compile.

You can create a pair of global variables and prime them with the HTML segments. Then, in the appropriate embeds, Target.Writeln(FirstString) and Target.Writeln(SecondString). Again, you have only one maintenance point and propagation on re-compile.

You can further break the strings down into pieces, similar to the example in the IC tutorial. You would then concatenate the pieces and Target.Writeln the concatenation. This allows you to use different images on different pages:

Target.Writeln(PieceOne & '/ImageOne.Gif' & PieceTwo)

in one place and

Target.Writeln(PieceOne & '/ImageTwo.Gif' & PieceTwo)

Target.Writeln(Clip(PieceOne)          &|
WebWindow.Files.GetAlias('Image2.gif') &|
'"width="40" height="7"' & PieceTwo)

(the latter is, formally, more correct) in another.

Carried to extreme, you could easily have different <table> setups for different conditions. I suppose you could even have different setups for different days of the week, if you wanted.

Different Browsers

All the screen shots are from Internet Explorer 4.01 (SP1) or Netscape 4.05. These two interpret and implement HTML in a fairly similar manner (though Netscape does tend to use more horizontal screen real estate).

In IE3.02, we see:

Figure 7

This ... ah, unattractive appearance is caused by two factors. First, IE3.02 does not size HTML buttons to the size of their contents. 4.x series browsers do resize elements.

Second, I created the page using relative amounts of space (percentages for <table> and cell widths) instead of assigning a fixed number of pixels of width.

Perhaps something like this might encourage your customers to upgrade their browsers (and, thereby, acquire a whole new crop of bugs). Perhaps you don't mind this or perhaps you are willing to use a fixed width. Your call.

Summary

You do not have to decaffeinate to make your application look just like any other Web page. But it does help (decaffeinating gives you back the band width you need for the graphics; be careful, though, enthusiasm can cancel out any band width gains quite quickly). The point is that you can make your IC app look like something that (you think) it isn't.

The fact of the matter, however, is that if you do apply the caffeine-free techniques, the primary distinction becomes the tool you used to create the page(s). Your page is indiscernible from any other Web page.

Liebniz might not approve of the re-wording of his Principle of the Indiscernability of Identicals, but "If it looks like a duck ..."