Web based School
ActiveX Scripting |
 |
 |
Chapter ThreeActiveX ScriptingYou have learned that ActiveX programming involves
the manipulation of documents and other objects over the Internet. You also know that the
Internet consists of a diverse population of client and server machines. With all these different types of control objects
available to the programmer, a language must be used to manipulate those objects. This
language should have the added functionality of being able to work well over a distributed
environment like the Internet. In this section, you will learn about:
Client-Side Scripting.
Lights, camera, ACTION! No, that's not what
scripting is about, but there are some similarities. Client-side scripting is a way to
define procedures that manipulate the properties, methods and events of an object. The
script itself is executed on the user's local machine rather than on some remote server. Running a server-side script once for each
connection that requests it can be very taxing on the system resources of a busy server
(such as WWW.Netscape.Com or WWW.Microsoft.Com). Memory and storage can become gobbled up,
and processing speed deteriorates as more and more redundant code is loaded, run, and
unloaded (see Figure 3.1). This resource drain can be relieved somewhat by the
use of HTML client-side scripting. Client-side scripting shifts the code processing burden
from the server (which would have to run zillions of instances at once and transmit the
queries and responses back and forth over the Net) to the client (which would only have to
run one instance at a time—locally). For a graphical representation of this kind of
bottleneck, see Figures 3.1 and 3.2. In the preceding figure, the server must run a
script five times in one minute, unless the five hosts can simultaneously run one script
each in one minute. When you are browsing the Web, you are using one
host to access information on any number of other hosts. Scripting can occur on either
side of that connection. For example, the server to which you are connecting could run an
ISAPI, CGI, Perl or other script, and your browser could run a bit of VBScript, JScript or
other ActiveX script. As powerful as most programming languages are at
full strength, they can provide strangers on the Net more access to your system than you
want them to have. A scripting language is usually a subset of another
language. For example, VBScript is a subset of Visual Basic. JScript is a subset of Visual
J++ (code named Jakarta). By restricting some processes that are normally
available, such as features of file I/O, programmers can use a hobbled version of a
programming language. This gives you some degree of protection against
malicious or undesirable programs. Features such as shelling to the operating system and
formatting the hard drive are simply not available through a good scripting engine . Scripts, Hosts and the Engines
Another difference between scripting and programming
is the way the finished program code is compiled and executed. A normal program is usually
compiled into an executable to be run by itself, or it can be compiled into a library of
features, such as a DLL (dynamic link library). A script, on the other hand, requires two
things besides itself to run—a host and an engine.
Script Hosts
In reference to scripting, a host is a program (such
as Microsoft Internet Explorer or Netscape Navigator) that uses a script engine to run a
script on the local machine. The host application is the intermediary program between the
user and the server, and resides on the user's machine. Any OLE program can act as a
script host when it implements either the IActiveScriptSite interface or the optional
IActiveScriptSiteWindow interface. Engine
In order for a host to run a bit of script, it must
reference a scripting engine. This engine is usually a library or set of libraries
(such as VBScript.DLL or JScript.DLL) that tells the host how to interpret the script.
ActiveX scripting is Microsoft's implementation of the HTML script element. Every ActiveX
scripting engine must implement either IActiveScript, or the optional IActiveScriptParse
interface. The script engine (that is, a runtime file or files
installed on the local machine) has a two-pronged approach to facilitating Internet
programming. First, script engines use all the objects in the
standard Internet Explorer Object Model for Scripting. This includes the document object,
the anchor object, the history object, and so on. Second, script engines also support a few objects
that are built into the engine itself. This extends the power of basic HTML scripts. If
these JScript, VBScript and MSIE objects are not enough, you can add other objects to your
document, as you will learn in the final chapters of this guide. Script
The script itself is the code, in whatever syntax is
supported by the script engine. The script can make reference to the various objects
supported within the context of the document. These include the document object and other
embedded objects (the final chapters of this guide, which cover ActiveX controls, present
these objects and object models in greater detail). For an graphical representation of how
client scripting works across a net, refer to Figure 3.3. Figure 3.3. The relationships
between the parts and pieces of ActiveX scripting. A script can be loaded into the system by one of two
interfaces. The whole script can be loaded using IPersist*, or a portion of the script can
be attached to an object using IActiveScriptParse . HTML Scripting
Although it's not necessary to be a fully qualified
OLE programmer to use most forms of script, it certainly helps. Programming and scripting
are very similar. In fact, early versions of Basic (such as those found on the Radio Shack
TRS-80 and the Commodore 64/128) were not as powerful as most of today's elemental
scripting languages! Programmers do their thing within one or several
programming languages. These languages define the way you control processes on your
computer, and are usually very powerful. On newer machines that have APM (advanced power
management), a programmer can write a program that actually turns off the computer for the
night. Script writers, on the other hand, are dealing with
a somewhat less powerful environment. This limited environment disallows most hardware
control features without actually disabling them. For example, a script writer can make
the user's computer play sound files in MIDI and Wave format, but the script writer cannot
install the drivers that play those files. The drivers would have to already be installed
on the client machine. The Script Element
The insertion of client-side script into an HTML
document requires the <SCRIPT> container tags to define pieces of text within that
document that are code segments. The script element has three attributes (two of which are
optional). These include the SRC, Type and Language elements. A <SCRIPT> tag looks
something like this: Because some browsers do not support the
<SCRIPT> tag, this tag is sometimes ignored. This becomes problematic when content
is displayed because the content and the script become mixed together. Older browsers (such as Mosaic and Lynx) usually do
support the <COMMENT> tag, so make your pages friendly to non-ActiveX browsers by by
adding <COMMENT></COMMENT> tags around your code. These tags are ignored by
the script if the browser can run them, and filters out the text of the script if the
browser cannot run them. This format for coding script looks like this: The Language Attribute
The primary attribute of the script element is the
Language attribute . The Language attribute is the only attribute that must always be
specified. Normally this will be VBScript or JavaScript because these are the two primary
scripting engines used by the two primary Web browsers. The SRC Attribute
The optional SRC attribute tells the browser that
the code for this entry can be found in an external file. In the preceding example, the
code is in a file called, VBScript.vbs in the current directory. The Type Attribute
If you refer to an external source file in a script
tag, you might need to use the Type attribute to define the MIME type for the script file.
For instance, in the preceding example, the code is in a text file with a .VBS extension.
The user's browser will retrieve the script the same way it retrieves text/vbscript MIME
type files. JScript and VBScript
When using script within an HTML file, the best
place to put your code might be at the top of the file (within the head element). Code can
be placed in a later portion of the document, but it must be before the </HTML> tag.
One reason to place code at the top of a file is if the code actually writes to the
file. Often, people speak of ActiveX scripting. There is
no "ActiveX Script" language per se. ActiveX script is the name given to
the use of OLE interfaces in a scripting engines. Jscript and VBScript are the usual two
that are referred to, because Microsoft includes their engines with MSIE (see Figure 3.4).
ActiveX script engines for Perl, LISP and others are also being developed. If, for instance, you were to use VBScript's
Document.Write method, the text that is written would need to be figured in before the
rest of the page is displayed. This ensures that the browser knows what to put where on
the page when the page is viewed. Figure 3.4. ActiveX script
shares objects, properties, methods and events with VBScript and JScript. Another reason to place code at the beginning of a
file is for procedures that, logically, would only be launched after the page is viewed.
This could include a procedure that would be launched when the user clicks a button or an
image map. Since the code is vital to the operation of the page, it needs to be loaded
before the rest of the page. One school of thought says to put every bit of code
in the head element to ensure that the script is available before the user needs it.
Another school of thought says to put some code at the end of the page so the text will
display more quickly. Additionally, you can place code in the middle of a
document, preferably near an object with which the code interacts. If you code your script
this way, most browsers will load and display the content of the document as it is
downloaded. When it gets to the object and the script, it will pause (or hiccup) as
it displays the content. During this pause, the object and code are grabbed from the Net
and are appropriately displayed. Placing the code at the beginning of the document
produces a pause at the beginning of the document. Depending on the size of the code, the
pause could last as long as a minute before the user is able to view the first line on the
page. In cyberspace, this seems like a lifetime and causes the user to choose another
page. As a rule, it's a good idea to place as much of your
script at the top of a page, or in an external file, if possible.
JScript
JScript is Microsoft's implementation of JavaScript.
System support for JScript is installed by default with Microsoft Internet Explorer.
Additionally, Microsoft maintains an excellent resource for up-to-date information related
to JScript development at http://www.microsoft.com/jscript.
The ActiveX Control Pad is a handy utility for
writing JScript code. Even more powerful than JScript is Visual J++ (also known as Jakarta),
which allows users to compile Java applets, OLE-level code and other high-power Internet
tools.
As with Java, JScript is (or soon will be) available
for a variety of platforms, including Mac, PC, and UNIX, and extending to Sun, HP and even
IBM platforms. VBScript
VBScript is another big Microsoft implementation of
HTML script. In many respects, VBScript is similar to JScript, with an additional twist. VBScript is a subset of VBA (Visual Basic for
Applications), which is a subset of VB (Visual Basic ), and can easily port applications
back and forth among the three. Going the other way, VB is a superset of VBA, and VBA is a
superset of VBScript. For a less confusing, graphical representation of this relationship,
refer to Figure 3.5. Figure 3.5. Visual Basic has
become a hierarchical family of programming tools. Some of the features within VBA that are not found
in VBScript include DDE (Dynamic Data Exchange) link features and declarations for calls
to external DLLs. VBScript also has significantly fewer debug and error handling routines.
For the person creating the script, these are handy. By eliminating these features,
however, the user does not need to install large runtime files on his local
machines—just small runtime files. You will learn more about VBScript later in this
guide . The ActiveX Scripting Engine
ActiveX supports the use of customized script
engines (that is, engines other than VBScript and JScript). ActiveX script engines can be
created for LISP, Scheme, SALT, Perl or even your own custom or proprietary language. Developing your own programming language is a very
complex process (don't even try it unless you know what you are doing!). Creating a script
engine for a pre-existing language is only slightly less difficult. This chapter does not go into all the details of
creating your own engine. To do so requires a much larger volume. But for those of you who
need your own script engine, or are developing one for the open market, there are a few
features of ActiveX Scripting with which you should be familiar. If you just plan on using engines created by others,
such as VBScript and JScript, you will want to be familiar with how the engine works. You
will also want to know how it crashes. Host and Engine Interaction
There are several steps involved in making a
connection between a host (such as Microsoft Internet Explorer) and an engine (such as
VBScript).
The Engine as an OLE/COM Object
If you are an OLE or COM programmer, you can create
your own scripting engine using a program such as C++. Required Interfaces
To qualify as an ActiveX script engine , your
project must support the IActiveScript interface. This gives the OLE programmer access to
the basic scripting features of the engine. The control must also support at least one of the
following IPersist* interfaces :
Engines and the Registry
ActiveX engines are added to the system registry in
two component categories: CATID_ActiveScript and CATID_ActiveScriptParse. If the engine's CLSID is entered in CATID
ActiveScript, it must support IActiveScript and one of the IPersist* interfaces mentioned
earlier. However, if the engine's CLSID is entered in CATID ActiveScriptParse, it must
support IActiveScript and IActiveScriptParse interfaces. Engine States
An ActiveX script engine can exist in any of several
states. The programmer who creates the engine might find it necessary to monitor these
states, and to enable or disable functions of the engine as these states change. This case
logic can ensure that users are not able to attempt impossible tasks, such as trying to
disconnect from a server that was never successfully initialized. UnInitialized
In this state, the engine is little more than an
idea. No program has called it and no program is using it. Initialized
In this state, the script has been initialized (that
is, called) but has not yet started connecting to the referenced objects and event
handlers that it will need to run. Started
In this state, the connections have still not been
made, but code that was loaded during initialization can be run automatically. Connected
In this state, the engine is going full-tilt boogie.
All the connections to objects and events have been made, code is ready to execute, states
are being monitored and events are firing. Disconnected
In this state, the script is still loaded into the
engine, but it has been disconnected from all objects and events with which it might have
been communicating. The script is not automatically reset, however, because that would
send everything back into the initialized state. This would cause your script to run
endlessly. Closed
In this state, the script is over with, whether it
completed normally or not. If it was communicating with other objects in the system, it
should tell them when it closes. If external objects try to reference it after it closes,
it will just return a bunch of errors . Figure 3.6. The features of an
ActiveX script engine . Summary
You should now have a strong familiarity with the
features of ActiveX scripting. It allows the use of a variety of general and specialized
scripting languages. Client-side scripting relieves an Internet server of much of the
burden of processing multiptle simultaneous requests. You also know about the two major script engines
supported by ActiveX, JScript and VBScript. JScript is Microsoft's implementation of Sun
Microsystem's JavaScript, which was the first wide implementation of HTML scripting.
VBScript, which is part of the Visual Basic family of programming languages, is very
similar to JScript, but is aimed more toward today's front-end developers who use Visual
Basic and Visual Basic for Applications. You are also aware of the basic interaction between
a script host, engine, and code. (A full definition of the script engine interface would
include several of the OLE features represented in Figure 3.6) A host is a program that
manages scripting functions by coordinating the retrieval of a script and the processing
of that script by an engine. A script is a bit of code written in a scripting language,
which can be run by a script host, such as Telix, Internet Explorer or Netscape. An engine
is the files and routines required to interpret, compile and run a script. Prospective OLE programmers have been introduced to
some of the features of a script engine, such as the processes it uses and the OLE
interfaces it implements. Q&A
WorkshopList some of the programming features you use in
Visual Basic that you would not want available in a scripting engine (for security's
sake), then list some of the programming features you use in Visual Basic that you would
consider indispensable in a scripting engine (for security's sake). Quiz
|
|
|
Popular Tutorials
-
MS Access
1109
-
C++
1222
-
HTML
584
-
JavaScript
616
-
Vbscript
873
-
Oracle
473
-
VC++
875
-
SQL
2959
-
XML
514
-
Java
814
-
Perl
455
-
Linux
451
