New York
University
Computer
Science Department
Courant
Institute of Mathematical Sciences
Active Server Pages
Course Title: Application Servers Course
Number: g22.3033-011
Instructor: Jean-Claude Franchitti Session: 3
In November 1996, Microsoft formally introduced the Active Platform at the Site Builders Conference and the Professional Developers Conference. At those events, the audience saw a picture of the "Active Platform" shown below, that outlined the major parts of Microsoft's vision of the future of Internet development. The two pillars of client-side and server-side scripting share a common tool set and are both based on consistent standards and protocols.
The Active Platform was Microsoft's vision of the
next generation of distributed computing. It exploits the best of the
centralized programming models as well as the best of decentralized
programming. The Microsoft vision has profound implications for the Internet
(not merely for industrial-strength client/server programming) and for the way
that systems are developed and deployed. Microsoft's model creates applications
that are logically centralized and physically decentralized. A logically centralized system can be
administered from anywhere. Such a system is conceptually simple, and when
properly tooled, is easy to manage. Physically
decentralized systems can be more efficient, fault tolerant, powerful, and
scaleable.
The most striking thing about the Active Platform picture is that both sides of the diagram are almost identical, evidently different only to the extent of system services.
Scripting
Client-side scripting and server-side scripting have
different missions in life. Client-side scripts most often add improved user
interface and data validation (when HTML forms are used). Server-side scripts,
especially in Active Server Pages, are practically unlimited; but they are
primarily used to capture business rules and access to data (the second and
third tiers in 3-tier client/server programming).
The important thing to stress here, however, is that
server-side can, if properly implemented, create client-side scripts. One of
the most important questions in Internet development is the one that makes you
choose between programming to the broadest audience and programming for the
richest on-line experience. To the extent that you choose the former,
server-side scripting is important for two reasons:
·
Server-side
scripts can sense the capabilities of requesting client programs.
·
They
can be as powerful as you, the designer, want, regardless of how thin the
client is.
For example, the thinnest client on the Internet is the one that cannot render graphics of any kind. The ALT parameter of the IMG tag in HTML originally was intended to help such clients interpret important parts of the screen that they otherwise couldn't see, by describing the area in words instead of an image. With an Active Server Page, your application can sense when such a browser (for that's what these kinds of programs are-as opposed to Web client programs that have more processing power) is making a request of your Web site. You can then present such graphics-challenged browsers with whole paragraphs, not merely short expressions, to give them as much information as possible, given their inherent limitations.
In today's Internet, a major difference between Web
clients brands is whether they recognize ActiveX controls or not. Again, the
Active Server Page doesn't care one way or the other. If it senses the ability
to interpret ActiveX controls, it presents them; otherwise, it includes static
images (or text, if necessary).
Of far greater importance than these mundane issues is the fact that Active Server Pages promote a new level of processing power into the Web server. It is critical to remember that the Web server was never designed to be an application server. It was designed to deliver HTML. This remains its primary mission, even on the Active Platform, but with Active Server Pages, this design constraint ceases to be a constraint at all.
The scripts that are contained in Active Server Pages, especially those driven by Active Server components, bring virtually all the power of traditional client/server programming to the Web server. Indeed, to the extent that Active Server components are utilized, Active Server Pages can do things that even the most sophisticated client/server programs can't.
Components
Components may be the single most important feature
of Active Server Pages. Their importance to ASP is understandable when you step
back and see how pervasively Microsoft has embraced components in virtually
everything they create. Everything from the Internet Explorer to Windows NT 5.0
has been "componentized" by Microsoft engineers. Components give
programmers many advantages, including lower development time and cost, added
flexibility, easier maintenance, and most important, easy scaleability.
For the ASP development community, on the
server-side, server components are either intrinsic to the Active Server or
they are user-defined. On the client-side, ActiveX controls provide
functionality similar to server components.
Active
Server Components
Active Server Components basically do two things.
First, they directly expose operating system services to your Active Server
Pages. Second, they encapsulate business rules in a way that is extremely easy
to program. Perhaps even more important in the long run, Active Server
Components are easy to create. That is, by using programming tools and
environments optimized to work with the Active Platform, writing sophisticated
server components is no longer the province of the advanced programmer.
There is a truism in programming that the best
programmers are users. Active Server components will prove that not only to be
true but important, as well. In the summer of 1996, it was estimated that the
number of lines of Visual Basic code finally exceeded the number of lines of
code written in COBOL, the perennial champ. Perhaps the biggest reason Visual
Basic is so prolific is that users, not professional programmers, wrote these
"extra" lines of code. Active Server component development will bring
the same ease of programming to the Internet that Visual Basic brought to
creating Windows programs.
To get a feel for what server components are and what they do, take a look at a few of those that ship with the Active Server.
The Browser Capabilities component is the component that permits an Active Server Page to determine what kind of browser or Web client program is making a request. It makes this determination by looking to the User Agent HTTP header and looking up the identified browser in the browscap.ini file. All of the listed features of the browser are exposed as properties of the Browser Capabilities component.
The Browser Capabilities component is a clever piece of code, but it doesn't have anything to do with the operating system. One component that does get closer to the OS is the TextStream component. This component relies on the FileSystem object, which, as the name suggests, accesses low-level file I/O. With this component, opening or creating text files in the directory system is simple and direct. Navigating through the files' contents is equally straightforward.
Choosing a Scripting
Language
Until the advent of the Active Server, programmers spent too much time worrying about infrastructure (e.g., programming Database Management System (DBMS) connections) and not enough time in their core competence (i.e., doing something useful with the recordsets fetched from the DBMS). By bringing the system services closer to the program and abstracting these services into server components, Active Server Pages promises productivity gains absolutely unrivaled in the history of computing.
The other feature of Microsoft's vision for Active
Server Pages is in one of Microsoft key design goals for ActiveX Data Objects: universal access, not universal storage.
This preference to know where everything is instead of collecting everything in
one place is the natural extension of the overall mission of Active Server
Pages-to keep things logically centralized and physically decentralized.
Active Server Pages introduced a whole new concept
to web development - scripting language of your choice. Before ASP came around,
the web development tools such as ColdFusion by Allaire required that you know
a proprietary scripting language (in the case of ColdFusion it is CFML). On the
other hand there was (still is) Perl, which with packages provides access to
databases and other functionality that you have come to expect from a web development
environment.
ASP provides a better way of doing things - it
modularizes the web development effort. It gives you the option of choosing
your scripting language, something most other web development tools do not
offer. While there are many scripting languages around, the two most prominent
are - VBScript and JavaScript. You can also use PerlScript, an ActiveX
scripting engine available from ActiveState Tools, Corp. that you can use for
scripting your ASP pages.
Going back to VBScript and JavaScript, a common
question that has been asked is "what is the best scripting language,
VBScript or JavaScript?" In reality, there is no "better"
scripting language. It all depends on what context you ask the question. Here
are some of the factors you may want to consider before settling on one.
a. Ease of Use
People will tell you VBScript is easier than
JavaScript, simply because it looks like the Visual Basic language. While this
is true, a programmer with Java experience may think otherwise. People with no
programming background may find VBScript easier to use because
·
It
is easier to understand owing to its English-like syntax. E.g. If you want to
get first 2 letters in a word, do Left(someWord, 2) in VBScript, whereas in
JavaScript you do someWord.substr(0,2)
·
There
is more ASP reference material with VBScript than there is with JavaScript.
·
JavaScript
is case-sensitive and VBScript isn't. While this argument is valid,
case-sensitivity helps people understand the syntax better.
b. Features
Both scripting languages are powerful in their own
right. JavaScript offers a rich set of object-oriented framework to work with -
you could create classes. But with its version 5, this functionality extends to
VBScript as well.
Again, sometimes people confuse power with lines of
code. Just because something can be done in VBScript with one line of code when
it takes three lines in JavaScript does not mean JavaScript is any less
powerful.
However, JavaScript and VBScript differ in some
features
·
Error handling:
There was no error handling mechanism in earlier versions of JavaScript (in version 1.2, they started talking about it in 1.3). VBScript on the other hand provides a small but sufficient set of error handling capabilities.
·
Arrays:
Handling multi-dimensional arrays is easier in VBScript than in JavaScript. VBScript arrays can easily be dimensioned and re-dimensioned. JavaScript on the other hand provides a great feature - associate arrays, something that can easily replace dictionary objects.
·
Collection objects:
With VBScript, one can
enumerate items in a collection using the For Each.. Next loop. This way, you
avoid using an index to get the value of any item within the collection.
Note: JScript version 3 supports an Enumerator object which
lets you loop through the collection without using any index.
c. Client-side Scripting
"Why?" you may wonder. Although
client-side scripting has nothing to do even remotely with the server-side, you
may find yourself considering this in some situations
·
This
factor becomes important when you have to work on a team and the team members
are new to scripting. Instead of climbing two learning curves, settle on one
language for both client-side and server-side scripting. JavaScript can be a
good candidate in these situations, as runs on most browsers. VBScript, on the
other hand, does not run on Netscape browsers, which at this time constitute
about half the browser market.
·
If
you are working in an Intranet environment where the standard browser is
Internet Explorer, you can choose either VBScript or JavaScript.
How about both JavaScript
and VBScript?
ASP not only supports multiple scripting languages, but it lets you mix languages within a single page. For instance, you can have both JavaScript and VBScript routines on the same page. This ability, while it offers flexibility, is not all that efficient when you have a large number of pages. Consider this only if necessary, when one language does not give you what you want.
Conclusion
You will have to choose a scripting language to write ASP pages, especially when you are new to ASP. The language should not become a holy grail, but instead you should give both VBScript and JavaScript a try before you decide what's best for you.