The Evolution Of HTML Scripting Pages

The evolution of HTML Scripting Pages

Active Server Pages (ASP) is a well known server side scripting technology.
This article will explain how this web technology can be emulated entirely on a
Windows client machine from within Internet Explorer (IE) using IE pluggable
protocols and Windows Scripting, to turn IE into an interactive programming
environment.  We will also examine the use of content storage files
as a sort of file database for use with pluggable protocols (EzHelp), and
detecting mouse-click events in WebPages and passing them through to the
containing application.  We will also deal with content storage file
security.  We will see how to put all of these new technologies together to
form a new and unique programming paradigm.

The use of the IE ActiveX control (IEX) in Windows programs is quite
compelling. Microsoft does it in limited amounts in products and tools such as
Outlook, and MMC. HTML offers fairly easy to produce multi-media content that
can be quite stunning in a Windows program. Furthermore, HTML content can be
changed without recompiling your program. This can be quite a handy thing.

There are, however, certain reasons that might stop someone from using IEX
and HTML content - mainly because of file exposure and file proliferation.
Typically, a WebPage is not simply a single file, but many files (such as
graphic files), that are referenced by a WebPage. Shipping several "raw" HTML
files with your product is potentially a bad idea because: 1) it can
dramatically increase the "file count" of your product. 2) if any of these files
are accidentally deleted, it may be difficult to ascertain which they are, and
3) raw files can be tampered with by end users.  All of these are good
reasons not to use them.  But there is a good solution to this problem -
the same solution that Microsoft uses. That is, the use of content storage
files and pluggable protocols.

IE uses pluggable protocols to obtain all of its content. Whenever you
type a URL such as

http://www.microsoft.com

IE looks up the http pluggable protocol in the Registry and loads the
appropriate COM object to go get the content. It is entirely the job of the
pluggable protocol to get the specified content resource, the way it knows how
according to its protocol. Once the resource data has been retrieved, the
pluggable protocol feeds it back to IE. The http pluggable protocol uses HTTP to
get the resource. The file pluggable protocol uses the file system to get
the resource.

EzHelp is an application program that provides a User Interface (or UI) for
creating content storage files. You create a storage file by dragging and
dropping files from Windows Explorer onto a treeview. As you drop files and
folders onto EzHelp, they are copied into a storage file, maintaining the same
hierarchy as your file system. You can create your own hierarchy as well. EzHelp
has an embedded IEX control that displays the content files as you select them.
To do this, it uses its own pluggable protocol developed for it. The ezh
pluggable protocol knows how to read the EzHelp content storage file. When you
select a file, EzHelp tells its IEX control to navigate to the file using the
ezh pluggable protocol.

So now you can specify the ezh protocol when to load a WebPage stored
within an EzHelp file. It has the following syntax:

ezh://drive:filepathfilename.ezh::/internalpath/htmlfilename

Example:

ezh://c:myezhfile.ezh::/myhtmlfile.htm

You can do this either programatically (using the Navigate method of IEX) or
type it in the address bar of IE.

I developed EzHelp for two purposes: 1) For an easy way to produce and ship
HTML-based product documentation, and 2) for the purpose of having a safe way of
storing content in a single file (for the reasons outlined above), for use by
application programs that embed the IEX control.

OK, at this point you have two tools that enable you to store your HTML
content in a single content storage file (EzHelp files) for use in embeded IEX
controls in your Windows programs. You can stuff all of your content files into
a single file to be shipped with your product, along with the ezh pluggable
protocol DLL. We have solved the original problems discussed above.

So we are now displaying HTML content in our Windows programs, and, thanks to
pluggable protocols, the content is retrieved from neatly bundled EzHelp files.
That's a big step forward. Now suppose you wanted to activate program functions
from mouse-clicks on the WebPage - a function that is outside the scope of IE.
For example, when you open Microsoft Outlook, and click "Outlook Today", you are
shown a WebPage in the right-hand window pane, with links and graphics on it.
Clicking on a link activates the corresponding program function. The IEX event
model doesn't pass through mouse-clicks, so how are you going to know when a
link is clicked? The WOW control (WOW is for Web On Windows) handles this by
wrapping the IEX control and doing some special magic to pass these events
through to your program as an event. Now, when the user clicks on a link, you
could activate an internal program function, such as displaying a dialog window,
or changing screens, or whatever. WOW lets you use the IEX more as a classic
ActiveX control that interacts better with its container program.

OK, displaying static HTML WebPages in your apps is pretty good. You can do
quite a bit with static WebPages in conjunction with the WOW control. But we can
take it a step further and have dynamic WebPages using a new technology
named HTML Scripting Pages, or HSP for short. HSP is a client-side, ASP
work-alike. Think of HSP as IE + pluggable protocols + Windows Scripting. HSP is
implemented in its own pluggable protocol, so it works seamlessly with IE. It
uses Windows Scripting (aka Active Scripting) to execute script code embedded
within HTML pages, just like ASP. The difference is that it all takes place on
the same machine - there is no WebServer involved.

HSP uses most of the same objects as ASP (eg. Session, Request and Response).
Each object has most or all of the same properties and methods as its ASP
counterpart. The reason not all objects, methods and properties are implemented
is simple: They are not needed in a client-only, single user environment. For
example, the AddHeader method of the Response object would never be needed since
there are no HTTP headers involved with a pluggable protocol.

HSP works with any Windows Scripting engine that supports scriptable
COM objects (IDispatch). HSP only looks for script in files with the .hsp
extension.

Suppose you have an HTML file with the following line in it:

When loaded by IE, this would be displayed:

If you had a QueryString or Form value passed with a user name, you could
write:

or just

HSP's pluggable protocol is hsp. You load an HSP resource in the same
way as any other protocol:

hsp://c:/myproj/myfile.hsp

When IE sees the hsp protocol specified, it loads the HSP DLL and calls a COM
object to retreive the specified resource. Although HSP will open and execute
"raw" files files from disk, that is not the way it is used in your deployed
applications. Rather, you stuff all of your HTML, HSP and other content files
into an EzHelp file (using the EzHelp tool). The HSP protocol knows how to read
EzHelp files. We do this for the reasons outlined above. But now that we have
executable program code in our files, it becomes even more important that end
users don't tamper with your files.

Note: You can take advantage of the new VBScript Classes - COM classes
implemented entirely in VBScript - to write reusable classes in your HSP
code.  Quite a powerful feature.

Note: Due to license control reasons, HSP will only execute a maximum of
10 lines of script code in a raw .hsp file.

To show real world examples of the use of HSP, the following case studies are
included.

There is a fellow in the U.S. who works for a county government. He had to
produce a survey, or questionnaire, to be sent to various people. The
requirement was that it would run on Windows. He decided to use HTML web pages,
which required the user to install Personal WebServer. Depending on their their
answers to questions in the survey, they would be displayed different content,
and asked different questions as the survey progressed. He was very unhappy
about having to install Personal WebServer on the user's machines, due to the
extra complication of setting it. Now he could write the same HTML survey
program using HSP without the need for Personal WebServer.

A friend of mine was tasked to write a demonstration Web application for the
company he worked for. This demo program was to be sent out to clients on CD and
run on Windows PC's without Personal WebServer. He ended up writing an ActiveX
control to read and write an Access database and display dynamic content in his
WebApp. It took him a lot of time and trouble to get it worked out and written.
Now he can use HSP to write future Demo programs with no complicated
work-arounds.

EzHelp has built-in security features that can make it impossible for
unauthorized or unlicensed persons to open, execute or examine the contents of
your EzHelp files. Without security, anyone would be able to run your HSP
application. Also, anyone with the EzHelp Viewer could view the contents of your
HSP EzHelp files, including your source code.

EzHelp has two levels of security: Password and Machine License. EzHelp
allows you to set a password on your storage file, so that it cannot be opened
unless supplied. You can also set a Machine License, so that the file cannot be
opened unless a license key is detected on that machine. To do this, the EzReg
product is required. You might require a password or machine license if you sell
your HSP program or you produce educational courseware that you need to copy
protect to guard your content and revenue.

Conclusion

These technologies introduce a totally new programming paradigm that, though
Windows centric, can be used in a variety of applications on a large installed
base of computers.  Virtually all Windows machines have Internet Explorer
installed.  If not, it can be obtained for free from Microsoft.  The
Windows Scripting DLLs are also free and readily available from Microsoft. 
Being able to write an executable program that can run in the IE browser or in
your own custom programs is quite an interesting prospect.  The browser
display actually becomes a sort of programmable whiteboard for a wide variety of
uses, using HTML and VBScript.