eXtropia: the open web technology company
Technology | Support | Tutorials | Development | About Us | Users | Contact Us
Resources
 ::   Tutorials
 ::   Presentations
Perl & CGI tutorials
 ::   Intro to Perl/CGI and HTML Forms
 ::   Intro to Windows Perl
 ::   Intro to Perl 5
 ::   Intro to Perl
 ::   Intro to Perl Taint mode
 ::   Sherlock Holmes and the Case of the Broken CGI Script
 ::   Writing COM Components in Perl

Java tutorials
 ::   Intro to Java
 ::   Cross Browser Java

Misc technical tutorials
 ::   Intro to The Web Application Development Environment
 ::   Introduction to XML
 ::   Intro to Web Design
 ::   Intro to Web Security
 ::   Databases for Web Developers
 ::   UNIX for Web Developers
 ::   Intro to Adobe Photoshop
 ::   Web Programming 101
 ::   Introduction to Microsoft DNA

Misc non-technical tutorials
 ::   Misc Technopreneurship Docs
 ::   What is a Webmaster?
 ::   What is the open source business model?
 ::   Technical writing
 ::   Small and mid-sized businesses on the Web

Offsite tutorials
 ::   ISAPI Perl Primer
 ::   Serving up web server basics
 ::   Introduction to Java (Parts 1 and 2) in Slovak

 

Intro to the Web Application Development Environment
The Display (GUI) Layer  

Previous | Next | Table of Contents

[The GUI Layer]

As we said earlier, the GUI Layer (sometimes called the "frontend") balances upon the tenuous border between the world of computers and the world of people. As such, it must perform the often-complex task of translating between human and computer languages.

In its role as translator, the GUI is responsible for two things.

First, the GUI must translate the desires, intentions, needs, and wants of people into executable, logical machine instructions. At the same time, the GUI must also translate computer-generated data into meaningful human-readable information.

This translation, as you might imagine, is no mean feat. In fact, in creating web applications, web developers will spend just as much time building a solid frontend as they will spend developing a dependable backend.

As a web application developer, when concerning yourself with the GUI Layer, you will most likely be concerned primarily with the use and manipulation of "UI Widgets" or "controls". Widgets are interface tools that clients can use to make their intentions, desires, and wants known to the program. Widgets could include buttons, scroll bars, grids, or even clickable images. Widgets should be almost intuitive to you as this is the bit of software we humans most often work with.

For the most part, if you see a new technology, you can recognize it to be a GUI technology if it allows you to create interfaces made up of widgets and allows you to access those widgets as necessary.

Understanding the Web Browser  
As you can probably guess, when it comes to the field of web application development, all discussions of the GUI begin with the web browser. At its core, a web browser is a software program that knows how to contact a web server (using the HTTP protocol), request a given document from that web server, and display that document returned by the server to a human user.

[Web Browser at Work]

Because the communication between the browser and server is better discussed as a function of the communication layer, we'll discuss it in the next section. For now, we concern ourselves mainly with the document display that is more classically a GUI Layer issue.

Typically, the document that is returned from the web server is formatted (according to some formatting instructions) by the browser so that when it is displayed, the document will look pretty (rather than just being displayed as plain text) or have some special functionality. All readers will certainly be familiar with HTML, the most ubiquitous web-formatting languages around today.

Most web browsers know how to take HTML-encoded text and display it according to the HTML formatting instructions. Thus, a web browser will take <CENTER><B>Hello Cyberspace</B></CENTER> and turn it into

Hello Cyberspace
.

NOTE: Of course, it is important to note that though the browser is indeed responsible for creating this framework for communication between the world of computers and the world of people, it is often the web application developer who must do the grunt work of translating actual bits of content between parties.

That is, the web browser's primary task is to provide a communication framework upon which a web application developer can build. In other words, though the browser knows how to get HTML pages from a web server and display them, it is the responsibility of the web application developer to design a well-navigable site with interesting and useful content.

A Short History of Web Browsers  
In terms of the use of a web browser by the mass public, the history of web browsers begins with LYNX.

LYNX is a simple text-based web browser primarily accessed via UNIX shell accounts that displays formatted HTML text (but not images). A sample of what you might see in a LYNX browser is seen below:

[Lynx Screen Shot]

Though revolutionary when it was released, LYNX does not brag about its user-friendly design. As you can see, though LYNX is perhaps the fastest browser on the market because it does not need to worry about graphical display, it is also the ugliest for the exact same reason. LYNX's text-based interface is actually quite clumsy (unless you are a blind user in which case LYNX rocks for its speed and text-based simplicity where other browsers tend to be useless).

NOTE: Why not just code to Internet Explorer? I'm often asked this question. And I have to say that to a large degree, the question makes alot of sense. Afterall, IE has all sorts of cool extensions like the XML parser and perhaps a better implementation of dHTML. And these days, it is getting to be that IE users are seeming to overwhelm Netscape users, especially on Intranets.

Well regardless of that, I still say that any serious web developer will always choose to develop in a cross browser way, even if that means giving up some functionality. Though this may cause you a greater degree of pain in the dvelopment process, it has important benefits.

For one, developing for the least common denominator keeps you sharp. When faced with a lean environment, you end up coding better. With less resources, you learn to be creative instead of lazy!

Further, the fact is that there are many clients out there that use other browsers as well as older versions of those browsers. Even if your applicaiton is speced out as "intranet-only", if it is a good applicaiton, it won't be long before it has to go out to external clients as well.

So it is better for you to design with that in mind.

In fact, soon after the development of LYNX, as the concept of web browsing took off, web browsers would quickly evolve into the graphical web browser species beginning with Mosaic, Mozilla, and finally browsers such as Navigator and Explorer (there are dozens of other browsers of course, we just name the biggies). These browsers offered a truly user-friendly graphical interface that turned bland library-like document archives into an exciting electronic frontier.

Consider the same page as above, viewed in Netscape and Internet Explorer!

[Netscape and Internet Explorer]

As you can see, the basic feature (display of HTML) of the most basic GUI web application tool (the browser) can have dramatically different results!

Basic User Interactivity with HTML Forms  
However, besides displaying HTML-formatted text to users, web browsers also provide a means to solicit data from users and send that data to web servers. They do so by using HTML forms.

The ability to create forms is really the beginning of a true, traditional web application. HTML forms allow web application developers to design standard input forms with widgets such as drop downs, text boxes and buttons. Users can enter in data dynamically using these widgets.

[HTML Form Widgets]

Behind the scenes, once the user enters in their data and hits a submit button, the web browser will collate the user defined values for the form widgets and submit them to the web server using the POST or GET methods of the HTTP protocol. Again, we will discuss the HTTP communication layer aspects in the next section.

What you should do at this point is get comfortable with the idea that HTML provides the syntax for defining forms and that browsers will help you process those forms.

NOTE: Besides dealing with HTML form widgets, web browsers also help you maintain application state. they do so by providing an interface for "cookies".

As you will see later, because HTTP is a stateless protocol, most web applications will need help "remembering" what has happened so far in their work flow.

Consider the example of a web store that might need to keep track of all the items a client has added to a virtual shopping cart. The web store application must keep track of the shopping cart items wherever the user goes on the website, or even whether or not the user leaves the website and returns later!

To help solve this problem of state maintenance, browsers keep a log of all the application activity locally in a "cookie" (an invisible widget of sorts). Applications can access the contents of the cookie so that they can maintain the state.

Extending the Browser with Plug-ins  
Though powerful and revolutionary as browsers were with their ability to display HTML, gather and send user data to a web server, and store cookies, they were a bit too limited to really drive the net revolution whose visionaries were demanding more and more resources and freedoms.

Why can't we drag and drop excel files into our browsers? Why can't we have more powerful form widgets like grids and trees? Why can't we have more powerful animation, font, and layout tools? These were the questions being asked of the browser manufacturers daily.

Unfortunately, browser manufacturers realized that in order to keep their applications quick and manageable they would need to keep their applications simple and lean.

As a result, browser manufacturers were unwilling to add all the features desired by the web application development community.

However, all was not lost. Early, innovative pioneers discovered that they could extend browsers not by building bigger browsers, but by plugging in smaller components into the browser as needed. In response, browser manufacturers provided an interface so that plug-in developers could get to work.

Plug-ins appeared right and left. Some of the most notable plug-in packages included Real Audio, Real Video, Shockwave, and Acrobat

These plug-ins were proprietary software tools that were browser aware and of which the browser was aware. Thus they could be executed by the browser when needed and could take advantage of the HTTP pipeline that the browser maintained. In the beginning, plug-ins appeared as separate applications to the user with their own windows. However, over time, plug-ins became encapsulated by the browsers so that they appeared more cohesive to the web surfer using them.

Fortunately for everyone, plug-ins brought functionality to the web browser without forcing web browser manufacturers to add it themselves. This meant that features could be added more quickly without the browser developers as a bottleneck and that the browsers themselves would not become bloated. Object-oriented design at its best!

Java  
One plug-in that was actually integrated into the browsers almost as soon as it was released, was Java from Sun Microsystems. Java was a programming language that could be used by anyone to code add on features that would be executed within the context of the browser. The browsers added Java Virtual Machines to interpret the Java code downloaded from web servers.

In fact, the browser became a sort've worldwide desktop upon which application developers could distribute their own full featured applications with high performance scalable widgets such as trees, grids, tables, image buttons, etc.... Consider the following screen shot of an embedded applet that looks to be a fancy looking HTML page but which is much, much more.

[A Java Interface]

Java was originally developed at Sun Microsystems in 1991 to provide a platform-independent programming language and operating system for consumer electronics (TV sets, toasters and VCRs).

In syntax and execution, Java is a lot like a simplified version of C++. ("simplified" should be read in the previous sentence as "an improved"). It is a highly robust, distributed, high performance, object-oriented, multi-threaded language with all of the usual features. As such, it builds upon years of C++ development, taking the good and dispensing with the bad.

As it so happened however, Java did not make it into the consumer electronics market. Instead it wound up in our web browsers.

Java seemed to be a perfect fit for the web. The language itself was extremely small (as it was built to go inside toasters and alarm clocks with tiny amounts of memory). Thus it could quickly be transferred over the web.

Further, Java was platform independent. That is, any computer with a Java virtual machine can run a Java program. Programs can be written anywhere and be run anywhere. This is crucial because if a language can not run on any machine, it cannot be used on the web that must service every machine, language, and environment imaginable.

Platform independence works because Java is an interpreted rather than a compiled language. Unlike C or C++ code, when Java is compiled, it is not compiled into platform specific machine code, but into platform independent byte code. This byte code is distributed over the web and interpreted by a virtual machine (typically built right into a web browser these days) on whichever platform it is being run.

Thus, as a programmer, you need only concern yourself with the generic Java programming language and compile your applications into bytecode on whatever system you are using. You can then be assured that your bytecode will be executed correctly whether your clients are using Macs, Pcs, Unix boxes or anything else.

What's more, Java was a full-featured programming language complete with a more complete collection of user interface widgets in its AWT library, networking capabilities, database connectivity, internationalization features, and much, much more.

Though Java was sadly reduced to tickers and bouncing balls for the first few years of its life, by now, many high quality, production applications have been completed and are running happily with java served through web pages.

NOTE: To a certain degree, I also like to think of client-side Active-X components as plug-ins. Active-X technology allows web browsers on Microsoft systems to leverage the vast resource of Windows.

Like Java applets, Active-X components can be instantiated within the context of the web browser itself making it appear that the web browser is providing the functionality when in fact the Active-X component is simply piggy- backing off the browser.

Since any COM object in Windows can be an Active-X control, almost every Windows resource can thus be embedded in the browser window. Controls can be as simple as a custom stock ticker or as complex as an application like Microsoft Excel.

Consider the following screen shot of an Excel spreadsheet embedded directly into Windows Internet Explorer.

[Excel Document embedded in IE using Active-X Technology]

Of course, beware that Active-X is a Microsoft-specific technology so it may not ever work on Netscape or on Macintosh.

Exposing the Browser API with Client-side Scripting  
As you might imagine, adding all these add-on features to the web browsers began to cause problems. Specifically, distributing functionality in the form of Active-X controls, plug-ins, or Java applets could mean unacceptable download times for users.

In some cases, users would be willing to wait. Specifically, if the applications they required demanded the rich texture provided by plug in technologies, users would accommodate download times.

However, in other cases, users wanted a less complex solution. Granted, the solution should be more complex than HTML forms, but not necessarily as complex as Java.

Enter JavaScript.

Netscape 2.0 introduced JavaScript (initially LiveScript), a distant cousin of the Java language, as a means for achieving some special effects in the web browser without actually having to resort to a plug-in technology.

NOTE: Soon after the release of JavaScript by Netscape, Microsoft released their own semi-compatible version called JScript in Internet Explorer 3.0. JScript, however eventually lost much of its appeal after Microsoft released VBScript that leveraged the Visual Basic programming language to do the same thing as JavaScript.

VBScript would fast become Microsoft's preferred Web Language however because most developers like to keep their applications cross browser compatible, VBScript has receded to a large degree onto the server side for ASP which we will talk about later. Most client-side development is done in JavaScript.

Actually, to tell you the truth, JavaScript is a bit of a misnomer (or a marketing ploy) because though JavaScript is indeed a scripting language (browsers include a JavaScript interpreter), it actually is very different from Java. Whereas Java is a self contained programming language capable of full featured application development on its own, JavaScript is built as a programming glue that developers can use to tie other technologies (HTML or the browser itself) together within the scope of the web browser. That is, you would rarely say that you had finished work on a JavaScript application, but you might say that you had added some JavaScript functionality to your web page.

JavaScript is not so much about adding new functionality as it is about tweaking existing functionality to make it seem more cool.

The most important thing to understand about JavaScript is that it exposed much of the browser API to developers. Specifically, the browser and many of the widgets inside the browser could be talked to, listened to and controlled.

Developers quickly began to use JavaScript for such purposes as animation, accessing the bookmarks and history, event handling (like mouse over effects such as when a graphical image button lights up when the mouse crosses over it), form field validation (such as when you make sure the user has entered in data for all the required fields before you let them submit the HTML form to a web server), and the spawning of event dialogs and new windows.

What was nice was that JavaScript was written for the common person and required little programming background to master. Web designers could add a great deal more functionality and bells and whistles to their existing HTML pages without needing to resort to server-side programming like CGI.

JavaScript has gone through several iterations of versioning and though there are still compatibility problems between IE and Netscape, the standard features of the language have been nailed down pretty well.

Yet, almost as soon as it was released, developers realized that exposing the browser API was not enough. Client-side scripting languages, they realized, had the potential to be incredibly powerful if they were only given a bit more umph. Specifically, they need to have the document API exposed.

Enter Dynamic HTML....

Exposing the Document with the DOM and dHTML  
Dynamic HTML (dHTML) provides a way to combine plain HTML, cascading style sheets, and scripting languages into a much richer browsing experience. In fact, as dHTML becomes a reality, it becomes more honest to talk about fully client-side web applications that rarely need to contact the web server.

Like we'd seen with JavaScript and VBScript, dHTML exposes GUI widgets to the programmer so that she can manipulate them. However, unlike what we'd seen before with JavaScript and VBScript, developers had much more available to them beyond the browser and the form widgets. In fact dHTML has a much more diverse universe of widgets available to it.

This is because of the use of the Document Object Model (DOM) and style sheets (like Cascading Style Sheets [CSS])

The DOM is used to create virtual widgets out of the components of an HTML document. Using the DOM, for example, not only are the Netscape menu bar, bookmark list, and window accessible GUI widgets, but so are every paragraph in an HTML document, a table cell, and even an individual character of text. Each element in a document becomes a virtual widget.

Style sheets are used to apply style attributes to each of the elements in the DOM. Thus, a style sheet might define the margin, color, and size of a paragraph of text.

Since document components become widgets, they also become exposed to a scripting language like JavaScript or VBScript that can modify the attributes of their style just as they would modify the attributes of any other widget.

As such, a client-side scripting language can be used to modify any element on the page. Perhaps you want to make a word flash through a cycle of colors, perhaps you want to change the colors in a table depending on the data entered. Perhaps you want to generate a slide show. All this can be done on the client side using dHTML.

As you can see, dHTML is not so much as a technology itself as a synthesis of many technologies.

Unfortunately, dHTML is still very new and as such, has not been standardized between browsers. In fact, Netscape and Internet Explorer use almost completely different models such that many dHTML features will simply not work on both browsers.

However, like all web technologies, though there will always be cross platform issues of some kind, they will get more standardized over time. dHTML is one of the most exciting technologies released to this date, and promises to completely change the way web applications are created in a few years.

Summing up  
So as you can see, though there are quite a few technologies that fit into the GUI Layer, they are all tied together by the thread of widgets. All GUI Layer technologies focus on the presentation and manipulation of widgets on the client side.

However, at some point in the life of most web applications, the developer must send the information collected by the user from the GUI widgets, to the more powerful backend web server for processing. To do this, the developer must access the web server using the communication technologies provided by the web browser and web server. This involves passing through the Communications Layer.

This Communication Layer is the focus of the next section.....

Previous | Next | Table of Contents