Clarion 5.5 Web Development Features

by Steven Parker

Published 1999-11-09    Printer-friendly version

"CWIC2," as it is called by some, is not the name of the Web Edition upgrade (aka Clarion5.5). It is not even the name of its IC component. Because it supplements and extends the existing Internet Connect technology, I think it appropriate to refer to the new extension as "Internet Connect, the Next Generation." But, I know better. If you check the template registry, you will see that it is listed as "Web Builder Templates." So that is how it shall be referred to here.

In every relevant respect the Web Builder templates are revolutionary for Clarion developers. Or, to be precise, the technology underlying them is.

Just how different is Web Builder from its predecessor?

For openers:

• Java is not even an option in a Web Builder app (bye bye .CABs and .ZIPs);
• Creating dual-mode apps is now an option (and not even the default option);
• The new INIManager is also a cookie monster; that is, on a PC or network, INIManager methods normally affect .INI files, but on the Web set and read cookies (cool).

Figure 1. Enabling a web application.

Different enough?

No? There's more:

• Web Builder is ABC only, having been fully absorbed into the ABC collective;
• To say that there are a myriad of new Internet methods would be the understatement of the week (see Figure 2);
• If I decide to change the look and feel of an app, I no longer have to search through all the template prompts and embeds to find the code affecting the app's visual properties; changing one or two ASCII files will usually do the job (and they're not even part of the app).

Figure 2. New internet-related methods.

There has been a major philosophical change: Web Builder is designed so that a webmaster may change aesthetic aspects of an app, allowing full visual integration with an existing web site, without touching the actual executable or its functionalities. "Web-heads" can muck with an app but can't muck it up (at least, no more so than any other user). A web-head can make it look ugly but can't make it work ugly (only a developer can do that).

Different enough yet? Well, there's still more.

There is a built-in scripting language (TSSCRIPT) to help bridge Clarion to HTML. Scripts can be included without affecting the .APP or .EXE but only the generated HTML. That means that they can be added or modified independently of the .APP file.

Different enough?

Most visual tricks used with the previous version are no longer necessary.

However, if you need to be able to support every browser ever made, on every platform ever conceived (i.e., you are not allowed either Java or Javascript), you may not be able to use Web Builder. Web Builder, as delivered, relies heavily on Javascript (TSSCRIPT operates on the server side). So, if the "J" words are verboten, you may have to continue using the current Java-free techniques or, possibly, create a support structure that does not use Javascript. (The current Internet Connect templates will continue to ship with the product to cover this circumstance.)

In sum, Web Builder is an entirely new template chain with new method names and embeds. It is, simply, a whole new way of "going web."

Dual Mode

Before Web Builder, when you web-enabled an app, you automatically got a dual-mode application. With Web Builder, you must explicitly elect to create a dual-mode app. But if apps are not dual-mode, how do you test to make sure they work?

With the pre-5.5 IC product, you tested basic functionality in Windows. To test Web-enablement, you needed to have a web site, usually local to the development machine, available for testing purposes. You copied your app to the appropriate directory, started your browser and called your app. Then you tested again.

New in Web Builder is a "linked in broker." The linked in broker (LIB?) permits running an app locally on a PC without the full broker (apparently this is now called the Application Server, but you'll know what I mean if I continue with the older term, won't you?). The LIB does not eliminate the broker for Web deployment; it eliminates the need to create a local web site to test apps.

However, because LIB operates only locally (assuming, of course, that a browser and IP stack have been installed and that the appropriate DLLs and support files are available), an interesting consequence is that you can run an app in a browser locally. That is, you could deploy this way.

What happens is that, if your app is not dual-mode (i.e., is web only) and you press the make and run button, the broker will start, your browser will start and your app will be started in the browser.

Not only can you test functionality, you do so in a browser. This allows checking basic aesthetics and behavior in a production environment all at once.

Yes, if you double click on the .EXE from File Manager or Windows Explorer or from a shortcut on the desktop, the LIB will be called and the app started in a browser.

Convenient. Very convenient.

LIB can count: If you are already running a web server, the LIB will automatically bind itself to the next available port, port 81, before starting. If you are running a web server and have previously started the EXE broker, bound to an alternate port, the linked in broker will still bind itself to the next available port, port 82.

Very intelligent.

The New Paradigm

In Figure 1 you may have noticed a new template prompt: "Sub directory for skeletons." What is a skeleton and why does it need a subdirectory?

The new WB paradigm is actually a variation on something Clarion has been doing since Designer was first introduced in Clarion 2.0 (for DOS), something that has become so quintessentially Clarion that it often goes unremarked.

What is a Clarion .APP file? The standard answer is "a repository." And this is true. The .APP file is a repository of developer choices. It is also a database of those choices, options and entries and, in this guise, is used in a sort of mail merge. The Application Generator merges the templates with the data in the .APP to create Clarion source in the process we call "generation."

The new Web Builder paradigm is similar: it combines the .EXE with a set of HTML files located in this "Sub directory for skeletons."

Skeletons are simply HTML files accessible to (and deployed along with) your app. Each controls the appearance of a single web page element (corresponding to a window control).

There are skeletons for buttons, check boxes, entry fields, groups/group boxes, menu items, drop lists, menus, panels, prompts, radio buttons, regions, sheets, strings, tabs, text fields and browses. There is also one providing the general structure for a window, another containing common functionalities for all windows and one for colors of different page areas.

At runtime, these HTML files are read and their properties stored. When pages are actually created, window elements are merged with the appropriate HTML skeleton based on the properties best matching the control's requirements. This "merging" produces the final page element.

So, a skeleton is, in fact, a sort of control template for producing HTML.

To take advantage of the linked in broker, your skeletons must be visible to your app. Typically, this means they are deployed in a directory below the development directory (you simply name a directory in the template prompt - you may hard code a reference to another directory, should you wish). The necessary files are installed to a subdirectory called \DISTRIB. A PUBLIC directory will also be created and, as before, images are deployed there.

In short, the app (still) controls behavior and basic control location; skeletons control and fine tune appearance.

The flexibility is that the appearance of an element can be modified by changing, not the app, but the relevant skeleton.

For example, DisplayText.htm

<!-- DisplayText.htm -- Start -->
  <TSSCRIPT value=DisplayText>
  This is the text
  </TSSCRIPT>
<!-- DisplayText.htm -- End -->

controls the production of prompts and strings. If you would rather have those controls display using Verdana bold, just change DisplayText.htm:

<!-- DisplayText.htm -- Start -->
<font size="2" face="verdana"><b>
  <TSSCRIPT value=DisplayText>
  This is the text
  </TSSCRIPT>
</b></font>
<!-- DisplayText.htm -- End -->

and, voila, prompts and strings now use that font.

In light of the prompt in Figure 1, it is should be possible to have multiple skeletons affecting the same page element. Multiple skeletons would be used to make different procedures look different from one another. It should also be possible to use different skeletons for different controls of the same type within a single procedure or within a single app. That is, it should be possible to nominate alternate skeletons in two different ways.

And, indeed, this is the case.

Obviously, you may simply modify the shipping skeleton. In this case, all controls constructed from that skeleton will exhibit the properties specified in the modified file. Using the modified DisplayText.htm, above, all prompts and strings in all apps executed against the same skeleton directory would be Verdana bold.

If, for example, you prefer prompts and strings in Arial, modify DisplayText.htm accordingly and it will be made so the next time you access the app in a browser.

Additionally, you may create a new skeleton, based on an existing one and save it to a different name (or, same name, different directory). Then, on a control-by-control basis, name the skeleton to use:

Figure 3. Specifying a skeleton to use.

In this case, only the one control will be different.

Now, that's power. And skeleton mods can be done on the fly too (at least as long as no app is actually accessing the skeleton at the moment you save it). No matter how you cut it, this is vastly easier than a re-make. (Besides, the broker lets you stop an app and web-heads keep even weirder hours than we do. So, teach them how....)

Oh! Did I mention that skeletons can be customized in a visual HTML editor?

Summary

It sounds simple: the Clarion app controls functionality and placement of page elements, the skeletons (official name, "WebStyles") control appearance. This appears to delegate the substance to the Clarion developer and the superficialities to the web-head.

As a long-time subscriber to the Theory of Competitive Advantage, this strikes me as entirely appropriate and just.

Unfortunately, it doesn't always seem quite that simple. The very simplicity of the interaction easily confuses many.

In coming articles, I'll peek a bit deeper under the covers and expose more of this interaction.

---

Printer-friendly version

Copyright © 1999-2009 by CoveComm Inc. All Rights Reserved. Reproduction in any form without the express written consent of CoveComm Inc., except as described in the subscription agreement, is prohibited.

Clarion Magazine ISSN 1718-9942