Thin and Smart Web Clients
by
John B. Moore
Micro-Phyla Systems
Introduction
Imagine a highly interactive application technology that requires no client setup or installation, a technology where all clients get the most updated version instantly upon accessing their application, where all the code is managed from a central location. An application that loads fast and immediately responds to the user. An application that is both thin and smart.
Applets appeared to promise this dream, but paradise did not quite live up to this billing – the "Applet Hype". We will not belabor why applets failed to deliver, but a quick review of the following points will summarize the problems.
All of this adds up to a very slow, difficult to test and deploy, "write once, test everywhere" application. Smart but large and slow; not quite what we are after.
For a complete overview of the issues of deploying and developing with applets, see the attached Appendix A to this paper. The purpose of this tutorial is to examine the technologies that are maturing and coming of age that can be combined to provide smart and thin web clients. Our focus will be on:
One word of caution: There are entire books on each of these topics. Therefore this quick overview leaves out much and may, by virtue of simplification, leave out something you might consider important. Its purpose is only to "get you started" and help develop a feel for how these technologies can be applied and demonstrate some ways in which they can interact. For this reason I have added to the discussion of each technology a "Links" and sometimes a "Books" section to help you further your studies.
Thin and Smart Components
In addition to the basic idea of thin and smart, there are a number of design features that a "Thin and Smart" web client should aspire to achieve.
Can we have all of this at the same time? Realistically, maybe not. How close can we get? That is what will be explored during this tutorial. First, each technology will be reviewed to provide an outline of its strengths (Plus) and weaknesses (Minus). Then the task will be to develop an application that uses many of these technologies as an exercise that you can take with you to build on for your own projects.
A Feature Matrix
Following is a simplistic matrix that will give you a quick overview of how these technologies relate in providing the desired goals. Much more detail will be provided in the next section of this tutorial.
Key:
x = Strong support
o = Limited or Qualified support
blank = Virtually non existent, or difficult at best
- = Does not apply
|
Technology |
Goals |
||||||||
|
Deployment |
Zero Install |
Platforms |
Functionality |
Performance |
Stateful |
Presentation |
Maintenance |
|
|
|
HTML |
x |
x |
x |
|
x |
|
x |
o |
|
|
DHTML |
x |
x |
o |
x |
x |
|
x |
o |
|
|
JavaScript |
o |
x |
o |
o |
x |
o |
o |
|
|
|
Servlet |
x |
x |
x |
|
x |
o |
x |
x |
|
|
JSP |
x |
x |
x |
|
x |
o |
x |
x |
|
|
Applets |
o |
o |
|
x |
|
x |
|
o |
|
|
Java WebStart and Related |
x |
o |
x |
x |
x |
x |
x |
o |
|
|
XML, XSL, et al. |
x |
o |
x |
o |
x |
- |
- |
x |
|
The Players - An Overview
This section of the tutorial will review each of the listed technologies and how they can contribute to our stated goals, how they interact with other components, and their inherent weaknesses. Technologies like ASP and VBScript are omitted, not because they do not provide valuable functionality, but because of the author’s predisposition toward more cross platform solutions and the limitations of time.
HTML
HTML is the ubiquitous technology we are all familiar with as we use the Internet. It needs little introduction.
Plus
HTML has very wide and universal support from all browsers. There are markup tags that work better in one browser, and maybe not at all in another. Despite that, it is fairly easy to write universal HTML markup pages. HTML easily provides support for many of our goals as shown in the "Feature Matrix". It is easy to deploy by just copying the files into the correct document directory of the web server. There is no client installation and nearly all-modern OS platforms support the basic specifications. Performance is very good at all currently available bandwidths and it provides the thinnest of clients. HTML is the ultimate in "Thin"
Minus
With all of those strong features going for HTML one would think the search is over. Sadly, it is what is missing that makes HTML fall so very short of the desired technology to deliver on our goals. HTML is flat, linear, page oriented and static. Pure HTML provides no interaction with the user and only via the <FORMS> tag does it allow the user to send information back to a server or other target. It is, by design, stateless, unidirectional, and view only. This is great for displaying static documents or creating simplistic AGuest Books@ (assuming at least a CGI script to receive the Post from the <FORMS> submit tag.). Therefore, even though it appears at first glance to provide a lot of the desired features, there is little Abeef@ toward our application oriented goal. HTML, the ultimate in "Dumb", is a pretty shell that requires other enabling technologies to truly deliver.
References
Links
HTML Goodies - http://htmlgoodies.earthweb.com/ A Great beginner resource.
Document Object Model Dissected -
http://wdvl.internet.com/Authoring/DHTML/DOM/ - Good overview of the Object model. Important especially when using JavaScript.
HTML - The HyperText Markup Language -
http://wdvl.internet.com/Authoring/HTML/ - This entire website has dozens of tutorials on all aspects of web design. This link is a good starting point.
HTML 4.01 Specification -
http://www.w3.org/TR/REC-html40/ - This is the official site for HTML specifications.
Books
HTML Goodies – ISBN – 0-7897-1823-5 – A very good beginners book.
The Complete Reference - HTML - ISBN 0-07-21197-2 - Great Reference book. It has EVERYTHING.
HTML, The Definitive Guide - ISBN 1-56592-175-5 - The usual great reference from O’Reilly books.
DHTML
DHTML is a collection of "features" that has been added to the standard HTML. Style sheets, Cascading Style Sheets, Document Object Model, and JavaScript make up the general components that are needed. Dynamic HTML allows a web page to change after it’s loaded into the browser. There doesn't have to be any communication with the web server for an update. It is an "alphabet soup" of standards and versions and a good collection of reference books at your side is a must! The project examples demonstrated in this paper use only a fraction of the possible DHTML features. The simple reason was time. Take a look at any one of the reference books and it will be clear that this could be a week long tutorial by itself.
Plus
The good news is that this collection of "features" will make your website sing. It never ceases to amaze what can be done in a browser window. If you are lucky and have a single target browser as a client, then there is little in the way of restrictions to what can be done. Style Sheets help tremendously in standardizing your "look-and-feel" and allow dynamic changes to the look of the website. Cascading Style Sheets (CSS, CSS-P, and CSS2) standards outline a host of features that will provide a truly dynamic flavor to your web page without adding to the burden of maintenance. Add to this JavaScript (ECMAScript) and you then have even greater levels of control as well, and interaction with the user. (See "JavaScript" in its own section below).
Minus
Versions, lack of standards compliance, and varying levels and implementation of standards are only a few of the painful realities that the DHTML author must confront. The only way to navigate this morass is with a good reference book at the minimum and a lot of good links to web sites. It is not for the faint of heart. If you are developing a website that must be accessed by the general public, you must be very careful in this area. The more of the "features" that are used, the more testing is required to maintain compatibility.
References
Links
Dynamic HTML - http://wdvl.internet.com/Authoring/DHTML/ - Nice introduction to DHTML.
Dynamic HTML Tools and Resources -
http://wdvl.internet.com/Authoring/DHTML/Resources.html - Speaks for itself.
Dynamic HTML Lab - http://www.webreference.com/dhtml/ - A LOT of great resources.
Books
Dynamic HTML - The Definitive Guide ISBN 1-56592-494-0 – A "must-have" book. Don’t even try DHTML without a book like this one.
DHTML & JavaScript - ISBN 0-13-086334-3 - Under the theory if one book is not clear enough, another might help.
JavaScript
JavaScript is Netscape’s cross platform scripting language for client and server applications that provides for the development of dynamic HTML pages. JavaScript provides the ability to create more sophisticated, interactive user interfaces on the client. Client-side JavaScript can be embedded directly in HTML pages and is interpreted by the browser at runtime and allows the developer to interact with the user in more application-oriented ways. JavaScript currently comes in four levels of specification: 1.0, 1.1, 1.2 and ECMA-262 (1.3). Like Applets, you need to be careful and stay at the lowest level if you require the broadest browser audience. JavaScript 1.0 was the initial version and the most universally supported. Unfortunately it was buggy and of very limited functionality, and is now considered obsolete. JavaScript 1.1, in contrast, is often considered the first usable version. JavaScript is currently going through the standardization process. The standard specifies a language officially known as ECMAScript, and the specification is called ECMA-262. Officially MS Internet Explorer supports a version called JScript. JScript went from "1.0" compatibility directly to "1.2" compatibility. In situations where you know your audience’s browser, you can work accordingly. In cases where your target audience is all Internet Explorer browsers, then you might consider using VBScript instead. In the spirit of keeping with the broadest browser audience we will try and stay as close to JS 1.1 for this tutorial.
JavaScript versions go with the following browser versions:
|
Browser Version |
Netscape |
MS Internet Explorer |
|
2 |
JavaScript 1.0 |
|
|
3 |
JavaScript 1.1 |
JavaScript 1.0 |
|
4 |
JavaScript 1.2, not fully ECMA-262 compliant |
JavaScript 1.2, ECMA-262 compliant |
Plus
JavaScript is a lightweight and increasingly complex scripting language that will allow the developer some level of interaction and control within the HTML page. Events from the user can be monitored and appropriate interactions can be coded. Validation of input can be coded to provide some immediate feedback for simple validation such as; valid dates, date ranges, checking for blank values, etc. Dynamic HTML can be generated within the browser without any need to return back to the server allowing immediate control of content and appearance. JavaScript allows for a number of features not available to Java alone, such that combining JavaScript and Java enables considerable functionality. Java cannot control the browser, JavaScript can. Java cannot control or access cookies, JavaScript can. JavaScript can invoke Java. Java can invoke JavaScript. They make a powerful team.
Minus
Because the code is embedded in the HTML document, it makes maintenance difficult. It is possible and very desirable to keep most of your JavaScript code in ".js" files. This will minimize the problem. There is the danger of embedding application tier logic into the delivered client code. The last and most significant problem is, unless you stick with the most basic JS, you will face problems with different browsers, and of course, that limits the functionality of what you can do with JavaScript, as well as adds complexity to testing and development.
References
Links
JavaScript World - http://www.jsworld.com
JavaScripts - http://www.javascripts.com
JavaScript Goodies - http://www.htmlgoodies.com
JavaScript FAQs http://www.faqts.com/knowledge-base/index.phtml/fid/53/
JavaScript Tutorial for Programmers - http://www.stars.com/Authoring/JavaScript/Tutorial/index.html
Books
JavaScript Goodies ISBN 0-7897-2024-8 - Great Introduction.
JavaScript - The Definitive Guide - ISBN 1-56592-392-8 - The usual quality O'Reilly book. A book to sit down and read.
JavaScript Application CookBook - ISBN 1-56592-577-7 - Sample code galore.
Pure JavaScript - ISBN 0-672-31547-5 – A "must-have" reference book.
JavaScript - Annotated Archives - ISBN 0-07-882364-1 - More great samples of code.
Servlets
Servlets are units of Java code that run on the web server as an extension. The web server can provide native hooks to the servlet, or this service can be provided by a third party product like JRun, Tomcat or ServletExec. Functionally, the servlet behaves very similar to an ISAPI or NSAPI extension or CGI. Generally, the typical functions of servlets are:
Plus
In a great part, many of the services provided by servlets have been long provided by other technologies; CGI scripts and ISAPI/NSAPI extensions. So why servlets? A brief comparison of servlets to these other technologies might be useful.
Servlets vs. CGI
CGI (Common Gateway Interface) is a language independent interface that allows a web server to start an external process, which then receives information via environmental variables and returns a response to a standard output stream. CGI scripts must be fired up with each request as a separate process. Servlets have a number of significant advantages over CGI
Servlets vs. ISAPI/NSAPI extensions
Because of the "Sandbox" concept, a wayward servlet will not bring down the web server unlike a wayward ISAPI extension. Also ISAPI/NSAPI extensions are proprietary to IIS and Netscape servers (there is some support on other web servers, but often limited), whereas with the advent of Servlet Engines (Tomcat, JRun, ServletExec), servlets can be used on most any OS/Web Server platform combination.
So how do servlets contribute to our goals? Because servlets run on the web server and can communicate via HTTP as well as other protocols, they provide a central "engine" for providing dynamic web pages or a controller for JSP pages and database functionality. They can be easily tied to other distributive technologies like CORBA, RMI, and EJB. The client remains very thin, as all processing can be done at the server. Servlets can provide state at the server side, as well as writing cookies or URL rewrite to track a client.
Minus
The primary shortcoming of the servlet architecture is on the client side, where user interaction is limited by the interface provided by HTML, JavaScript, and even an applet which present their own limitations and issues. Hence, the servlet provides no value to the client application interface, and is totally dependent on other tools to provide that functionality.
Another issue related to this is that the client interface must be generated or delivered by the servlet. This can tie the application server tier with hardcoded client interface code, making it more difficult to maintain. The solution to this last problem will be provided by JSP in the following section.
On the state issue, though servlets can provide a lot in this area, it is still to varying degrees, dependent on features and functionality on the client to insure a stateful connection.
References
Links
The Servlet Source - http://www.servletsource.com
ServeletForum.com - http://www.servletforum.com/
Servlets and JavaServer Pages (JSP) 1.0: A Tutorial -
http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/ - There is a book as well. A good study guide.
Books
Java Servlets - ISBN 0-07-135188-4 - Great Examples and a good starter book.
The Java Web Server ISBN 0-201-37949-X - A web server and the code to make it work. Valuable insight on web servers, and the introduction covers a lot of basics.
JSP - JavaServer Pages
JavaServer Pages is a server side technology that uses HTML as the "template" with XML-like tags and scriptlets written in the Java programming language to encapsulate the logic that generates the dynamic content for the page. Additionally, the application logic can reside outside the page definition in server-based resources (such as JavaBeans component architecture) that the page accesses with these tags and scriptlets. Any and all formatting (HTML or XML) tags are passed directly back to the response page. JSP fits nicely with the Servlet technology discussed earlier, and allows the development of templates that will provide dynamic content. It is important to note that when the JSP engine loads a page, it compiles it into a servlet. This means that from that point on, it parallels everything that was listed about servlets.
Plus
JSP allows the separation of the page logic from its design and display and supports a reusable component-based design. This effectively allows the application logic to reside on the application server tier and provides tremendous maintenance improvements.
Together, JSP and Servlets provide an attractive alternative to other types of dynamic web scripting/programming tools, which offers platform independence, enhanced performance, separation of logic from display, ease of administration, extensibility into the enterprise, scalability, and ease of use.
Over the last year we have seen a tremendous growth of work in extending this technology. In addition to Custom Tag library development projects and JavaBeans, there a number of architectural patterns that can define the relationship between JSP, JavaBeans, HTML and Servlets. These architectural patterns also provide maintenance benefits and should be seriously investigated. These patterns, such as "Model-View-Controller", "Dispatcher", and "Service to Workers", to name a few, came about to solve problems and provide structure and maintenance features. Using Servlets as a controller or dispatcher, factors out considerable amounts of Java code that would be needed to authenticate users and route requests based on special conditions or business logic. Another approach is to utilize an existing framework or develop your own framework. Examples of such frameworks are; Cocoon, Resin and Struts, to name a few of the more common framework projects
Minus
The JSP tools needed to make this easy to build and maintain are still in their "teenhood" but are developing rapidly. JBuilder is part of this push to make JSP and Servlets easier and faster to develop. The good news is that a lot has happened in the last year and I expect that to continue.
References
Links
Servlets and JavaServer Pages (JSP) 1.0: A Tutorial -
http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/ - There is a book as well. A good study guide
Java Server Pages - http://www.javasoft.com/products/jsp/index.html
JSP Resource Index - http://www.jspin.com/
The Jakarta Project - http://jakarta.apache.org/ - Reference Implementation.
JDance - Good collection of JSP links and resources. http://www.jdance.com/jsp.shtm
JSP Introduction. The Java Developer ConnectionSM (JDC) presents a Short Course written by JavaTM Software licensee jGuru (formerly named the MageLang Institute). This short course provides an introduction to JavaServer PagesTM (JSPTM) technology. http://developer.java.sun.com/developer/onlineTraining/JSPIntro/contents.html
Framework Links
Cocoon is a 100% pure Java publishing framework that relies on new W3C technologies (such as DOM, XML, and XSL) to provide web content. http://xml.apache.org/cocoon/
Resin® serves the fastest servlets and JSP. With Java and JavaScript support, Resin gives web applications the flexibility to choose the right language for the task. Resin's leading XSL (XML stylesheet language) support encourages separation of content from formatting. http://www.caucho.com/
The Struts Framework. The goal of this project is to provide an open source framework useful in building web applications with Java Servlet and JavaServer Pages (JSP) technology. Struts encourages application architectures based on the Model_View_Controller (MVC) design paradigm, colloquially known as Model 2 in discussions on various servlet and JSP related mailing lists. http://jakarta.apache.org/struts/
Books
There are a lot of books available now on JSP and Servlets. What I have listed here is what I consider the "Top Four" in my library of over a dozen books on this topic. I added a brief comment as to why I consider it a member of this group.
Core Servlets and JavaServer pages, Marty Hall, ISBN 0-13-089340-4 Very good "basic" reference book with useful examples. (Some books have such trivial examples)
JavaServer Pages, Larne Pekowsky, ISBN 0201704218 If you want to "read a book from beginning to end" on JSP, this would be the one. Simple, clear and well organized. A good place to start.
Professional JSP, Karl Avedal, et. al., ISBN 1-861003-62-5 Some great code examples, the best I have found. More of a reference, though some chapters are worth reading if that is an area in which you are focusing.
Java Developer’s Guide to Servlets and JSP, Bill Brogden, ISBN Code examples that are not found in most other books. Good XML examples using SAX and DOM parsers.
Applets
For completeness we will briefly review the features that applets will provide. A more complete discussion of this technology can be found in Appendix A. Therefore I will not repeat that information.
Plus
Applets provide a very sophisticated platform for client interaction, depending on the JDK that you are allowed to use. Interaction with data and graphics can approach the kind of sophistication you would expect from a standalone application. There are situations where only an applet can provide the functionality needed. (Though you might want to investigate the Java WebStart discussed following this section.) Some examples of appropriate use of applets can be found at http://www.javasoft.com/features/1998/07/applet.power.iii.html.
Stateful interaction between the client and the server is considerably easier because the client can actively communicate with the server as needed.
Minus
All of this sophistication comes at a price. A lot of code must come across the wire. This becomes a serious performance issue over the Internet, less so in an Intranet environment. JDK issues become a serious drawback if you require a broad Internet audience. Again, controlled Intranet systems can control the browser versions and utilize the Java Plugin.
Deployment can be a major challenge for database applet, because of all the different components that must be configured to work together. Utilizing servlets and then communicating the data via http protocols can simplify this considerably.
References
Links
Applet Deployment http://www.microps.com/mps/papers.html (Also available as the appendix to this tutorial.)
See additional References at the end of Appendix A.
Java Webstart and Related
Around about 1997-8 Borland (then Inprise) released the Deployment Server for Java (DSJ). This was an idea whose time, apparently, had not yet come because the product was soon dropped. I always believed that this concept had promise, and regretted its demise. Now Sun has finally picked up the ball on this same idea and released the first version of Web Start. It may prove to be the answer to all of those dreams of what Applets could have been. In addition there are a number of third party products available: Deployment Director from Sitraka is one such product.
Java WebStart - a new application-deployment technology – promises to provide the ability to launch full-featured applications with a single click from the Web browser. Using this technology a user can download and launch applications, such as a complete spreadsheet program or an Internet chat client, without going through complicated installation procedures.
With Java WebStart, simply clicking on a Web page link launches applications. If the application is not present on the client computer, Java Web Start automatically downloads all necessary files. It then caches the files on your computer so the application is always ready to be relaunched anytime you want - either from an icon on your desktop or from the browser link. And no matter which method is used to launch the application, the most current version of the application is always presented to the user.
Plus
The full-featured application interface has a number of benefits that are very appealing:
Unlike traditional applications that are often complicated to install, and even worse to upgrade, this type of technology merges the advantages of Applets without the problems, limitations, and hassles of the browser.
Applications written on the Java 2 platform for deployment with Java Web Start are always up-to-date and available. Every application runs in a dedicated Java Runtime Environment (JRE), independent of a specific browser or computer platform technology. Java Web Start supports:
This will be interesting technology to watch and test. I will not be covering WebStart in the demos to follow, but I would strongly recommend investigating this solution.
JBuilder provides a Wizard (found under New|Web) to help setup a WebStart launcher.
Web Start Launcher Wizard
This wizard creates the .jar file and can create a basic "homepage" to use as a starting point. (Also note there is a "how to" link below with detailed instructions.)
Minus
Like any new technology, regardless of the pluses, they are still dependent on careful configuration, setup, a lot of rough edges, and coordination during development. This is a new area that has a lot of promise and there are a number of vendors that are showing up to support this idea. It should mature very fast. The only other real negative aspect found with the technology is the potentially heavy load that a company's network might have to undertake in deploying the technology to hundreds or thousands of users. But because it's deployed only once, it seems a small price to pay.
Links
Sun Microsystems Further Invigorates Client Side Java Technology with Java Web Start Software http://java.sun.com/pr/2001/03/pr010314-02.html
Java Web Start Version 1.0 Release http://java.sun.com/products/javawebstart/
Java Web Start Release Demos http://java.sun.com/products/javawebstart/demos.html
Java Web Start Release README http://java.sun.com/products/javawebstart/docs/readme.html
Java Web Start Release FAQs http://java.sun.com/products/javawebstart/faq.html
Java Web Start Release Developer's Guide http://java.sun.com/products/javawebstart/docs/developersguide.html
The Java Network Launching Protocol & API (JSR #56) http://java.sun.com/aboutJava/communityprocess/jsr/jsr_056_jnlp.html
A good beginning "How to" http://www.esus.com/javaindex/j2se/javawebstart/plugingetstarted.html
XML, XSL, et al.
The related XML (Extensible Markup Language) technologies are more of an "enabling" technology and not a "standalone" solution. The simplicity and flexibility of XML has lead to many proposed uses. The application areas for XML can be divided into four major areas:
XML is a subset of SGML and allows for the creation of custom "tags" (hence the word "extensible"). These custom tags must be documented in a Document Type Definition structure that can either be part of the XML file or reside separately. A DTD provides the lexicon and syntax for the documents that refer to it, providing a means where an XML document can be validated to ensure that the document is properly constructed. The DTD can also be referenced such that any recipient can use the same DTD to understand your XML tags, and therefore understand your document. XML Schemas is another way to define an XML document and is rapidly replacing the DTD. It has the advantage of being more "readable" and utilizes much the same syntax of XML to define the XML document. It has an additional benefit of defining data types, which allows an XML document that is being used for data transmission to be "self-defining".
Plus
The key to XML rapid popularity is its simplicity and easy to read format. Though many other formats, like a binary format, are significantly more efficient both in size and performance, this often does not outweigh the reality that a human-readable format will often prevail. It appears to be increasingly supported by all the major vendors and if this continues, will become the de facto cross platform data format for transferring data and communications between heterogeneous platforms. XML’s power and popularity is derived from three major features:
Minus
"If you have a hammer, everything is a nail". Like any new technology, it is easy to see solutions where there are no problems. Keeping XML in perspective as outlined will, be important in making the most of this enabling technology.
References
Links
Annotated XML Specification - http://www.xml.com/axml/testaxml.htm
Doing It With XML, Part 1 -
http://wdvl.internet.com/Authoring/Languages/XML/Tutorials/DoingIt/
Books
XML and Java - ISBN 0-201-48543-5 - Great overview and introduction.
Java XML Programming - ISBN 1-861002-85-8 - Ideas, code and examples
XML Applications - ISBN - 1-861001-5-25 - More Ideas, code and examples
This completes the overview section of the tutorial. As mentioned earlier, this only scratches the surface in discussing the various technologies and their applications. It is hoped that the references provided with each topic will prove to be a valuable guide in your understanding of each technology. The main sessions of the conference will target specific techniques that you will now be in better position to understand. For our purposes, we focused on how these technologies might help us toward the very specific goals that we have listed. Next, we will work through some specific, but very simple applications of these technologies, in the attempt to demonstrate briefly the potential of meeting our goals that were listed at the beginning. The combinations we will review are not exhaustive, and are meant only to illustrate how the different technologies interact and enhance each other.
Tutorial Projects
Following are a number of sample projects. Each project illustrates the solution to a problem, or how two or more of the target technologies can work together to solve a problem. A word of warning. Through much of the following projects there will be up to four different "languages" being used; JavaScript, Java, HTML/XML and JSP Tags. Every attempt will be made to label each, but also be aware to look for the labels, as this can be a source of confusion. The Java (Servlets, JSP), of course is, handled in JBuilder, whereas the HTML is handled in HotMetal Pro 6, and the JavaScript in WebScriptor 3.1 by Code Generation. The five projects to be introduced are as follows:
HTML plus JavaScript
A pure HTML page that uses JavaScript only allows for a static view of data and involves high maintenance at the back end. The JavaScript is used to allow for posting to our database and doing some "pre-validation".
HTML plus Servlets, JavaScript (Part I & II)
Next, we add some backend intelligence to our application. This lowers the backend maintenance issue considerably, as well as allows JS to communicate dynamically with the Server. We now have something very similar to our Applet version with a "mid-weight", but thinner client.
HTML plus XML, Servlets, JavaScript
There are times when the native "Post" of HTML forms is insufficient to express the data relationships. Posting a single field with an XML string will solve this problem. In the reverse direction, there are times when you only want data back, and deal with it dynamically on the client. Again, XML will solve the problem. How this is all done is interesting, and amazingly simple.
HTML plus JSP, Servlets, JavaScript
Now we move more of the logic back to the server, and serve up dynamic pages where the processing occurs almost completely at the server. The page design is removed from the code so that the Java and JSP code does only the logic, not the layout and presentation.
A Commercial Application - CrimeView Internet
We have reviewed in detail a lot of different combinations of the outlined technologies. But how can this come together in a real-life application - A quick tour of a commercial application, CrimeView Internet, from The Omega Group, Inc.
HTML plus JavaScript
Problem
HTML by itself does nothing more than flat presentation. This is fine for presenting articles or text. But so much of what makes business e-commerce websites useful is the need to interact with the user. This project adds client-side JavaScript to provide user interaction. I have restricted my focus on the kind of interaction that makes the website more "functional" and have avoided the "pretty" eye candy.
Solution
It should be clear from previous discussions that HTML, by itself, would be nearly useless. Therefore, we will consider this project as the "bottom line" of functionality. In this example we introduce a basic layout that will be used in most all of the examples. Three basic framesets (See Appendix C for a small discussion on frames) are created; "Content", "MainFrame" and "TotalFrame". The opening documents in the frames will be "pretty" placeholders until the user decides what it is they want to do on this site. It is generally a very good idea to keep the opening window simple and fast loading. Nothing is more annoying than loading slow graphics before the user even has a clue whether your site is what they are after. Frankly, if a site does not load right away, I will hit "Esc" and move on. The Content window will contain "menu" buttons or small graphics. The user can use this menu to select their choices. The basic layout is shown in Figure 1.
Figure 1 Website Layout
For such a basic site, there is still interesting functionality. This functionality comes from the JavaScript.
The Order
When the user clicks the "Order" button the JavaScript calls the needed forms into play with:
parent.MainFrame.document.location = "SWidget_HTML_OrdList.htm" parent.FooterFrame.document.location = "SWidget_HTML_Total.htm |
The following displays two forms for the user to fill out. (Figure 2)
Figure 2 Order Sheet and Customer Order
The lack of a database means that all the products are hardcoded in HTML - a major maintenance problem, as well as limiting. BUT for a very small site, it might be usable. The user can click the products they want and complete the lower order form. Some validation is provided to make sure all the correct fields are completed.
There is no "server" to which to post data, therefore, the user "posts" the reply in the form of email. Again, very limiting, because the data would have to be either re-entered by hand, or a small program would have to be designed to gather email from that email address and parse the data back into a database.
If you are dealing with the need to design a commercial site, this all seems hokey. I go through this example for two reasons:
Accumulative Score Card
A quick reference back to the goals we outlined in the beginning: a "0-10" rating where "-" is non-existent, "0" is very poor and "10" is "as-good-as-it-gets". These scores are accumulative from the base score given for plain HTML ( 9,10,9,0,9,0,10,0). Each project either raises or lowers the relative score. Refer to the "Final Score Card" at the end for individual ratings.
HTML plus Servlets, JavaScript - Part I
Problem
In the previous project, the client seemed useful, but because there was no interaction with the server, the limitations made it nearly as useless as plain HTML. A one sided conversation, is not a conservation. Our website needs to respond to varied amounts of data, so that the HTML does not have to be altered for every change.
Solution
With the addition of Servlets to the mix, a significant component is added to allow the communication between the client and the server. A number of functions are instantly available:
We will review several demonstrations of how Servlets can be utilized to add functionality to your website.
Adding Servlet with JDBC Access
The first example simply adds JDBC access to the creation of the product page of our website. This version still misses the mark, because it simply dumps the table onto the page, but some of the code is instructive. The code that calls the new servlet controlled page:
parent.MainFrame.document.location ="http://microps-212:8080/servlet/com.microps.swidgethtml.SwHtmlProduct"; parent.FooterFrame.document.location = "SWidget_HTML_Total.htm"; |
This page requires that JavaScript be able to walk an unknown number of table items. To do this the servlet must set up the HTML so that JavaScript can discover what was selected by providing a unique name to each data element. The servlet handles this by appending a counter to each tag "NAME" in the following code.
while (qdsProduct.inBounds()) {
counter_i = ++counter_i; out.println("<TR>");
out.println("<TD WIDTH='20%'>"+qdsProduct.getString("PROD_CODE")+"</TD>");
out.println("<TD WIDTH='50%'>"+qdsProduct.getString("PROD_DESCRIPT") +
"<INPUT TYPE='HIDDEN' NAME='Price"+counter_i+
"' VALUE='"+qdsProduct.getDouble("PROD_PAR") +
"'></TD>");
out.println("<TD ALIGN='CENTER'WIDTH='10%'>"+
qdsProduct.getDouble("PROD_PAR") +"</TD>");
out.println("<TD ALIGN='CENTER' WIDTH='10%'><INPUT TYPE='TEXT' NAME='Text"+
counter_i+ "' SIZE='5'></TD>");
out.println("<TD ALIGN='CENTER' WIDTH='10%'><INPUT TYPE='CHECKBOX' NAME='CheckBox"+
counter_i+ "'VALUE='"+qdsProduct.getString("PROD_CODE") +
"'></TD>");
out.println("</TR>");
qdsProduct.next();
} |
The JavaScript to handle this, must walk the "Document Object Model" (DOM) of the form, appending the same counter to each name, and checking for data input. The following illustrates how this can be done:
for(i = 1 ; i<=count_i ; i++){
if (eval("theForm.CheckBox"+i+".checked")) {
if (eval("theForm.Text"+i+".value != '' ")) {
qty = Number(eval("theForm.Text"+i+".value"));
} else {
qty = 1;
}
price = Number(eval("theForm.Price"+i+".value"));
BaseTotal = BaseTotal + (qty * price);
}
}
|
The key method that makes this work is the eval() function. This provides the ability to dynamically create a string that can resolve to JavaScript and have the string "evaluated" as JavaScript. Notice how this function can be embedded at any point in the code. This is a powerful technique. The downside is that it can be a "bear" to write and, for a JavaScript newbie, even harder to read. This also would not be good from a maintenance perspective. This is an issue we need to solve. More on this issue later.
This project example utilized the first presentation structure that worked fine for a small set of products, but as the product database grows this structure quickly becomes unusable. The other problem is that the user has to do a lot of scrolling and, can quickly get lost in the maze. Not a good "shopping" experience. Maintenance is still a nightmare as mentioned above, but also a reminder that we have embedded a lot of presentation structure in "hard to maintain" code, not good.
HTML plus Servlets, JavaScript - Part II
Problem
Dynamic page creation from a database is nice, but in our first simple attempt, this not only overwhelmed the user with monster tables, but also left the client frustrated. And still there is the problem of gathering the client input and turning it into a form that can be posted back to the server. Also, there is the problem of keeping track of the user, and creating a "relationship" with that user as a customer.
Solution
The first change is in the presentation structure. The previous design allowed the user to view all products and browse and check off what they wanted. This becomes overwhelming very quickly. A better design is to create "categories" and allow the user to select a category of products. The next change is to allow the user to "buy" a single item at a time, using the ubiquitous "Shopping Cart" structure. With every purchase we refresh the FooterFrame with that user’s shopping cart. This adds a bit more response to the user on the purchase without requiring a trip back to the server with every need to "View" the cart. When shopping in a brick-and-mortar store one can always see the "cart". Therefore, utilizing the lower FooterFrame of the web page as the cart, the same effect can be simulated
The Logon
The first new component to the page will be the logon (Figure 3). This will allow tracking of customers and later many new features can be added that can utilize this information. At this point, just getting the email address and a password will suffice.
Figure 3 Logon to Web site.
The logon uses a fake "submit" button that triggers a JavaScript function that controls and manages all of the posting issues.
<SCRIPT LANGUAGE="JavaScript" TYPE="text/javascript">
function doLogon() {
var sEmail = "UserEmail="+document.LogonFrm.UserID.value;
var sPassword = "Password="+document.LogonFrm.Password.value;
if ((sEmail != " ") && (sPassword != " ")) {
parent.MainFrame.document.location = "SWidget_HTML_Splash.htm";
parent.ContentFrame.document.location = "Swidget_Servlet_Content.htm";
parent.FooterFrame.document.location =
"http://microps©212:8080/servlet/com.microps.swidgethtmlsrv.SWidgetLogon?"+ sEmail+"&"+sPassword;
} else {
alert("User ID and Password Required");
}
}
</SCRIPT> |
If you are familiar with how forms work there is a default button of type SUBMIT that will take the URL in the ACTION attribute and combine it with all the elements of the form into a request of either type "POST" or "GET". This is nice for very simple things and it was used in the first project. Once the page and the validation becomes complex, this often times is not sufficient. The solution is easy enough. Change the button to type BUTTON and add an ONCLICK event that triggers a JavaScript function. The HTML would look like:
<INPUT TYPE="BUTTON" NAME="Login" VALUE=" Login " ONCLICK="javascript:doLogon();">
Notice in the AdoLogon()@ function that multiple frames can be targeted with new HTML pages or the output of a servlet. Of greatest interest is the servlet output, where two parameters are passed to the servlet using standard HTTP URL syntax. The servlet then receives this request as an argument of the doGet() method:
| public void doGet(HttpServletRequest request, HttpServletResponse response) |
In the Java code, the parameters are extracted with the getParmeter() method:
String sUserEmail = request.getParameter("UserEmail");
String sPassword = request.getParameter("Password"); |
For this project customer validation is not done, nor is the email stored persistently. Instead a session object is defined and the email address is stuffed into the Session object for future uses:
HttpSession session = request.getSession(true);
String sesID = session.getId();
session.getParameter("USEREMAIL",sUserEmail); |
Finally, a response is generated, starting with setting up a response writer:
PrintWriter out = new PrintWriter(response.getOutputStream());
response.setContentType("text/html"); |
Then continue to write to the "out" stream with a simple HTML page that will show up in the previously assigned target frame (assigned by the javascript in the doLogon() function).
It does not take long to get tired of formatting HTML within Java. Later, JSP will assist in minimizing this drudgery. For now, a feature of javascript/HTML helps in this task which is that both HTML and JavaScript consider the single quote and the double quote as string delimiters. Note this in the following lines:
out.println("<BODY BGCOLOR='#FFFF00'>");
out.println("<TABLE WIDTH='100%' CELLPADDING='1' CELLSPACING='1'>");
out.println("<TR><TD><IMG SRC='images/smiling.gif' WIDTH='48'HEIGHT='48' BORDER='0'></TD>"); |
Without this "feature" the formatting task can still be done, but it would be made considerably less readable because of the heavy use of the backslash to insure that literal quotes could be inserted into the string.
Coding Tips
Everyone works out their own "techniques" as they attempt to work as efficiently as possible. I’ll be sharing some of the ways that I work in hopes that it will be helpful.
Embedding HTML in Java can be a boring task. To make it a bit easier, I generally develop and test the HTML in HotMetal, then a "search and replace" of all double quotes to single quotes. The last step is to cut and paste into the target class and wrap into the required "out.printlin("…") format, and then embed any replacement strings within that structure.
Finally the web page will be displayed, as in Figure4
Figure 4 Product Catalog
The Catalog
The catalog is displayed by clicking the "Product Catalog" button on the ContentFrame. This triggers the Catalog_OnClick() function and the JavaScript code:
parent.MainFrame.document.location = "http://microps©212/servlet/com.microps.swidgethtmlsrv.SWProductGrp"; |
This calls another servlet and loads it into the MainFrame window of the web page.
This will be the first servlet that requires database access. Therefore, the first task is to setup the database connection and perform the required query.
Database dbSmiley = new Database();
QueryDataSet qdsProduct = new QueryDataSet();
int counter_i = 0;
try {
qdsProduct.setQuery(new com.borland.dx.sql.dataset.QueryDescriptor(dbSmiley, "Select * from PRODGRP", null, true, Load.ALL));
dbSmiley.setConnection(new com.borland.dx.sql.dataset.ConnectionDescriptor ("jdbc:interbase://localhost/D:\\IBDATA\\SMILEYDB.GDB", "SYSDBA", "masterkey", false, "interbase.interclient.Driver"));
qdsProduct.open();
}
catch (com.borland.dx.dataset.DataSetException dsex) {
out.println("Database connection failed with error\n");
dsex.printStackTrace(out);
out.println("Database connection failed end error\n");
}
|
The error is simply pushed out to the web page. In a production system this would not be desirable, but for testing and development this is very helpful. It is important to remember to create a more user-friendly output in the final system.
Before sending the data to the client, it has to be wrapped properly in HTML. As mentioned earlier, this is not a difficult task, but tedious. The code can be broken up into three tasks: the header, the data, and the footer. The header provides the static top of the page as in:
out.println("</HEAD>");
out.println("<BODY BGCOLOR='#FFFF99'>");
out.println("<H1 ALIGN='CENTER'>Smiley's Widgets</H1>");
out.println("<H2 ALIGN='CENTER'>Product Catelog</H2><BR><BR>");
out.println("<DIV ALIGN='CENTER'><P>Select a product Category you wish to review and
then click");
out.println("the List Product button to view");
out.println("<FORM><TABLE WIDTH='60%' CELLPADDING='1'
CELLSPACING='1'>");
out.println("<TR><TD ALIGN='CENTER'WIDTH='65%'> <B>Product Category</B></TD>");
out.println("<TD ALIGN='CENTER' VALIGN='MIDDLE'WIDTH='15%'><B>List</B></TD></TR>"); |
Notice that the beginning of the table is set, and the first row <TR></TR> is set for the table header. Next, the core of the table is added with:
try {
while (qdsProduct.inBounds()) {
counter_i = ++counter_i;
out.println("<TR>");
out.println("<TD ALIGN='LEFT' WIDTH='85%'>"+qdsProduct.getString("PROD_GRPDESCRIPT") +"</TD>");
out.println("<TD ALIGN='CENTER' WIDTH='15%'>");
out.println("<INPUT TYPE='BUTTON' NAME='"+qdsProduct.getString("PROD_GRP")+"' VALUE='List Products'");
out.println("ONMOUSEDOWN='parent.ContentFrame.ProdList_OnClick(\""+qdsProduct.getString(
"PROD_GRP")+"\")'>");
out.println("</TD></TR>");
qdsProduct.next();
}
}
catch (com.borland.dx.dataset.DataSetException dsex) {
dsex.printStackTrace(out);
}
Above, the data is concatenated within the HTML document. In addition to regular HTML, there is embedded JavaScript for the ONMOUSEDOWN event that will provide the action of displaying that product group. This also points to a challenging formatting problem with double and single quotes. In HTML the event must be surrounded in a "quote" (single or double) and the agreement of the called function is also a string, hence the requirement of "quotes". Then Java has its requirements because it must print a string. This can get confusing, but the following is a simplified example of the above ONMOUSEDOWN example.
A EVENT== function(\@ A+datastring+@ \@ ) = @
Spaces in the above example were added for clarity. They are not required or needed. Notice the backslash-quote combination, which provides the required "third" level of quoting.
Lastly, closing the HTML document and wrapping up the dataset finishes the needed code:
out.println("</TABLE></FORM><P></P><P></P><P><I>Last Updated on "+(new Date()).toString());
out.println("</I></P></DIV> </BODY> </HTML>");
out.close();
try {
qdsProduct.close();
dbSmiley.closeConnection();
}
catch (com.borland.dx.dataset.DataSetException dsex) {
dsex.printStackTrace(out);
}
The only thing to point out in the above code is the ability to set the ALast Update@ at the bottom of the page. Let the user know this was as fresh and updated as is possible.
Javascript and AppServer 4.0
The Inprise Application Server 4.0 had two different problems with embedded JavaScript libraries. The first problem was in standard HTML pages, and the effect was to confuse the web browser such that it either did not load the library (IE 4+) or dumped the library into the window (NS 4+). Both effects are undesirable, to say the least. The solution was to set up a MIME type. In the property file:
..\Inprise\AppServer\properties\server\<serverName>\webpageservice\mime.properties
add the line:
# Mime Types
js=application/x-javascript
Next in the HTML page format, the SCRIPT tag is as follows:
<SCRIPT></SCRIPT>
<SCRIPT LANGUAGE="JavaScript" TYPE="text/javascript" SRC="javascript/swidget_serv.js"></SCRIPT>
<SCRIPT LANGUAGE="JavaScript" TYPE="text/javascript" SRC="javascript/swidget_prodlist.js"></SCRIPT>
Note the empty SCRIPT tag. That is not there by accident. It seems the extra "empty" SCRIPT tag is vital
The last problem had not found a good solution - only a tolerable workaround - and is related to the first problem. Basically, adding a SCRIPT tag to the response from a servlet, in some way halts the response sequence, because the browser will receive a "Document not found" error. Comment out the tag and everything works just fine. The workaround is to load all the SCRIPT tags on regular HTML, page in a frameset, and then reference that page in your JavaScript code. If you do not have framesets, there is no solution or workaround besides upgrading to BAS 4.5.
Accumulative Project Goal Score Card
This project added a lot in the ability to provide dynamic data to the client in a more usable form. It also set the stage for stateful interaction with the user. More can be done in building on this foundation. Tracking of the user’s preferences, their activity and choices, and dynamically changing the website based on the user ID, are examples of making use of the ability to maintain a session on the server for each user. Maintenance is still a problem. In some ways it is worse than the previous example because we have added a third language that has to be maintained. More importantly, we are still heavily tying the presentation with the logic of the system. A solution to this issue will not be found until JSP is examined. Deployment has become more complex. In addition to the HTML pages, the JavaScript library files, and images, there is now the needs to insure the servlets are properly deployed.
HTML plus XML ,Servlets , JavaScript
Problem
This combination addresses a problem that is coming up more frequently in real world projects. There is a need for a single "back-end" to serve multiple clients. Not all of the clients are known, so a communication protocol needs to be used that is both ubiquitous and highly standardized. Data needs to be transferred, and clients need a way to quickly understand the data format.
Solution
XML will be the core of our solution. Servlets will be designed that can receive an XML request over the ubiquitous HTTP protocol and return a reply in the same XML format as a response. The client platform/Language/OS is totally irrelevant to the process. As a bonus, we don’t have to deal with firewalls, special configurations, or other install issues. The DTD for the XML tags used could be sold or licensed, allowing other unknown clients to purchase the output of our system and become its own profit center. No longer are browsers the only target clients.
The XML Servlet
Keeping the servlet very simple for demonstration purposes, the single servlet designed for this task will handle the XML input as well as the output. In a commercial system it might be advisable to delegate this task to a helper servlet that receives all the XML coming in to the server. This servlet then parses all incoming XML. XML parsing is a topic in its own right, so the way it is handled in this project will be very simplistic. In fact, an XML request is not needed at all if there are task specific servlets that are called from the browser. Both ways will be outlined below.
XML Gateway
In this architecture, XML would come in as a parameter to a form post or a direct connection from an applet or Java application. The header of the XML request would be stripped off and read. This header would indicate the target servlet for this request and either pass the remaining XML to that servlet, or parse it internally to then pass the extracted parameters to the correct servlet. There are a number of architectural possibilities. Generally I would favor parsing the XML into a collection class and passing that to the target servlet. This keeps the overhead of XML parsing in one location, and passes a standard collection object, that is easy to access by the target servlet.
Simple Form Request Servlet
In a simple system, a servlet might have only one task to perform. There is no reason in this system for the XML parsing overhead. This project’s XML servlets are designed to send back either an XML reply of product groups with no input required, or run a query on a single input and return a reply of the result set. The first servlet, SWProdXMLGrp, will simply return a table of all product groups in the system.
Before getting into the details of the servlet construction and the JavaScript handling of the reply, it is important to step back and discuss the architecture of the HTML form used to communicate with the servlet via XML.
The HTML to Servlet Connector for XML
The HTML form has only one way to communicate with the outside world. This is the form tag "SUBMIT" button or the JavaScript submit() method. At it simplest, the form assembles the "ACTION" string with the name=value pairs of each form element. A simple "SUBMIT" could look like:
http://microps-212:8080/servlet/com.microps.swidgethtmlsrv.SWProductList?ProdGrp="BOTTLES"
Where the form’s ACTION tag was:
ACTION=@http://microps-212:8080/servlet/com.microps.swidgethtmlsrv.SWProductList"
And, there is a form input element named "ProdGrp" with a VALUE of "BOTTLES". The browser appends the name/value pair in the form of: ProdGrp="BOTTLES" with a question mark that separates the URL from the "query string". This is standard HTTP syntax. This works great for sending XML, because all that needs to be done is place the XML string as part of a input tag and the form will automatically create the name/pair query string.
The problem is coming back with a response. The only thing a browser can receive is an html page. The trick is to place the response within a <SCRIPT> tag JavaScript function, as part of an HTML page in which the function is set to fire on the page’s "ONLOAD" event.
Here is the whole step-by-step sequence. The posting HTML page looks like the following:
Step1 - The Page Format
<HTML> <HEAD> <TITLE>Processing page</TITLE>
<SCRIPT> </SCRIPT>
<SCRIPT TYPE="text/javascript" LANGUAGE="JavaScript">
function passXML() {
// Servlet writes XML here as a text var }
</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFF00" ONLOAD="passXML()">
<FORM NAME="ProcessFrame" METHOD="POST" ACTION="">
<P><INPUT TYPE="HIDDEN" NAME="XMLRequest" VALUE=""></P>
</FORM>
</BODY></HTML>
Step 2 - Update the Posting Page
At posting, JavaScript updates the form objects with the following code.
function sendXML(URLString,XMLRequest,theMode) {
if (okToSend) {
XMLMode = theType;
okToSend = false;
var theForm = parent.ProcessFrame.document.forms[0];
theForm.action=URLString + "&Form=True&Encode=True"; theForm.XMLRequest.value=XMLRequest;
theForm.submit();
} else {
alert("Response from previous request(s) not received.");
}
}
The importance of this code is that the form ACTION object is updated with the correct URL. Then the form input object named "XMLRequest" has its VALUE updated with the string "XMLRequest". After that, the form is submitted, using the JavaScript method submit().
Step 3 - Servlet Handles Request
The servlet receives the request and extracts the request with:
String sRequest = request.getParameter("XMLRequest");
If this is a regular XML request, it would next be parsed to extract the information needed to process the request. For the current servlet, no request is needed since the servlet will return the complete product group list. First, a string buffer is created to handle the construction of the response, and PrintWriter to handle the HTML output.
StringBuffer sbXMLResp = new StringBuffer();
PrintWriter out = new PrintWriter (response.getOutputStream());
Next, the first part of the return HTML response is sent to the outputstream:
out.println("<HTML> <HEAD> <TITLE>Processing page</TITLE>\n");
out.println("<SCRIPT TYPE='text/javascript' LANGUAGE='JavaScript'>\n");
out.println(" function passXML() {\n");
out.print("var XMLResponse = \"");
The StringBuffer is used to build the XML response with:
sbXMLResp.append("<DATATABLE tablename='PROD_GRP' rowid='PROD_GRP'>\n");
try {
while (qdsProduct.inBounds()) {
sbXMLResp.append(" <TROW>\n");
sbXMLResp.append(" <TFIELD colname='PROD_GRP' visible=false width='10'>"+qdsProduct.getString("PROD_GRP") +"</TFIELD>\n");
sbXMLResp.append(" <TFIELD colname='PROD_GRPDESCRIPT' visible=true label='Products' width='20'>"+qdsProduct.getString("PROD_GRPDESCRIPT") +"</TFIELD>\n");
sbXMLResp.append(" </TROW>\n");
qdsProduct.next();
}
}
catch (com.borland.dx.dataset.DataSetException dsex) {
dsex.printStackTrace(out);
}
sbXMLResp.append("</DATATABLE>");
String sXMLResp = sbXMLResp.toString();
The StringBuffer is converted to a string and then follows the most critical part of the process, the XML string has to be processed to make it safe to reside within an HTML document. The method EscapeXML.makeHTMLSafe(sXMLResp) is used. This method converts a number of characters that would cause problems for the HTML page, to their "escaped" equivalents with the exception of the space character as follows:
public static String makeHTMLSafe(String xmlstr) {
StringBuffer sBuf = new StringBuffer("");
char aChar;
//walk the string and examine each char, replace if on list
// otherwise re-add to string buffer
for (int i=0;i<xmlstr.length();i++) {
aChar = xmlstr.charAt(i);
switch (aChar) {
case ' ': sBuf.append("+");
break;
case '"': sBuf.append("%22");
break;
case '#': sBuf.append("%23");
break;
case '%': sBuf.append("%25");
break;
case '/': sBuf.append("%2F");
break;
case ':': sBuf.append("%3A");
break;
case '<': sBuf.append("%3C");
break;
case '=': sBuf.append("%3D");
break;
case '>': sBuf.append("%3E");
break;
case '?': sBuf.append("%3F");
break;
case '\\': sBuf.append("%5C");
break;
case '\n': sBuf.append("%0A");
break;
case '\r': sBuf.append("%0D");
break;
case '\t': sBuf.append("%09");
break;
default: sBuf.append(aChar);
}
}
return sBuf.toString();
}
This method basically walks the entire string and inspects each character, replacing any that meet the case list, or the default just appends the same character to the StringBuffer.
Lastly, the remainder of the HTML page is sent out to the response outputstream with:
sXMLResp = EscapeXML.makeHTMLSafe(sXMLResp);
out.println(sXMLResp+"\"");
out.println("parent.ContentFrame.processXML(XMLResponse);");
out.println("}");
out.println("</SCRIPT></HEAD><BODY BGCOLOR='#FFFF00' ONLOAD='passXML()'>");
out.println("<FORM NAME='ProcessFrame' METHOD='POST' ACTION=''>");
out.println("<P><INPUT TYPE='HIDDEN' NAME='XMLRequest' VALUE=''></P></FORM> </BODY></HTML>");
Step 4 - New Page Loads
The response page loads in the target frame with the BODY tag event ONLOAD.
<BODY BGCOLOR="#FFFF00" ONLOAD="passXML()">
The function passXML() is no longer empty and now has the format:
function passXML() {
var XMLResponse = A.....string in here....@;
parent.ContentFrame.processXML(XMLResponse);");
}
Figure 5 shows the raw XML, and Figure 6 shows the formatted XML after it is escaped.
Figure 5 Raw XML from Server
Step 5 - processXML() - Write the new Page.
This function is basically a long switch/case statement that respond to the "mode" set to process the reply. The following shows the structure of the function:
function processXML(arg_sResponse) {
arg_sResponse = replacePlus(arg_sResponse);
var sResponse = unescape(arg_sResponse);
okToSend = true;
switch(XMLMode) {
case 1:
displayProdGrp(sResponse)
default:
}
}
The function "displayProdGrp()" processes the XML, and in this case converts it to an HTML page that is loaded into the MainFrame. After the HTML header is sent to the page, the XML is extracted. This is done in two steps: First, the rows are extracted with:
var regEx1 = /<TROW>/g;
var arRows = arg_sReply.split(regEx1);
Figure 6 Reformated XML before parsing
Where arRows is an array. Figure 7 shows the row that is extracted.
Figure 7 Extracted Row
Next, walk the array and extract each field from the row with:
for(i=0 ; i<arRows.length ; i++){
if (arRows[i].length > 1) {
//split the Row into fields
var sRec = arRows[i];
var regEx2 = /<TFIELD/g;
var arFields = sRec.split(regEx2);
//extract field values here....
}
}
Figure 8 Shows the individual fields as they are extracted.
Figure 8 Extracted Field
Seems like a lot of work just to show a page. This is simply a demonstration of the technique. But how would this be a viable strategy? The best demonstration of where this technology is useful is to review a real application where this technique is implemented. The browser-based application CrimeView Internet from The Omega Group, Inc (www.theomegagroup.com) is just such an application.
This application is still in the final development stages, but it clearly demonstrates the utility of XML as an HTML client to Servlet communication. The XML provides dynamic information to any point in the HTML page, where JavaScript is used to dynamically utilize this communication to update the HTML client’s user interface without the need for disturbing the entire page.
Figure 9 The Omega Group's CrimeView Internet 2.1
Accumulative Project Goal Score Card
A lot was gained by adding XML functionality. Data can be retrieved without loading a page. Listboxes can be dynamically populated from the datasource. Data can be posted and validated back at the server, without the user being aware of the page changing - very similar to having a socket connection in a Java applet. We still have one very major problem - maintenance! This will be addressed next.
HTML plus JSP, Servlets
Problem
Maintenance. Up to this point, this has been a nightmare. Sadly, to a significant degree, these technologies will always be more complex to configure than a simple standalone application. There will always be the task of connecting the various distributed parts and keeping them interacting properly. It is, by its very nature, complex. Hopefully, everyone understands and accepts that basic reality. But that does not mean that a solution cannot be found that simplifies the process. Every gain will be worth it.
Solution
Java Server Pages (JSP) will provide a significant beginning to a solution. JSP allows for the separation of the presentation, the HTML document, and the back end logic code, in Java, (not counting the JavaScript). With care, the JavaScript can be minimized and more of the work can be done at the server end. The more this separation can be achieved, the better the maintenance. A quick reminder about JavaScript=s role in all of this "separation" - it is important to keep nearly all JavaScript code in libraries. Again keep the presentation layer simple and clean.
What does this separation buy? A small list for starters:
Sounds like a dream come true! Well, not quite - but it is a very good start. There are a number of levels of adding Java to the HTML page, and this has a lot to do with the degree of separation achieved.
A Minimalist JSP
Several years ago when I was first reading the specs for JSP I found it a bit confusing and wondered if this was really a step forward. Sometime later I discovered an amazing fact. To write a JSP, all one had to do was take any HTML file and change the extension to .jsp. This was great! I love technology that gets one going in the right direction so quickly and easily! After a bit of reflection, I realized that this is critical for JSP to have such a basic "entry point". In theory, an HTML author, not a Java programmer, could write the JSP layer. Having the entry point as basic as possible, keeps the learning curve for the HTML author start at a basic "known" and work up from that point. It is important to remember this basic fact - that any HTML document can be a JSP, without any changes.
Product Group JSP
For this project, the Product Group Catalog page will be converted into a JSP. The project begins with a very basic HTML that provides all the presentation elements that are desired.
<HTML><HEAD><TITLE>Product Groups</TITLE></HEAD>
<BODY BGCOLOR="#FFFF99">
<H1 ALIGN="CENTER">Smiley's Order Sheet</H1>
<H2 ALIGN="CENTER">Product Catalog</H2><BR><BR>
<DIV ALIGN="CENTER"><P>Select a product Category you wish to review and then click
the List Product button to view</P>
<FORM>
<TABLE WIDTH="60%" CELLPADDING="1" CELLSPACING="1">
<TR>
<TD ALIGN='CENTER' WIDTH='65%'> <B>Product Category</B></TD>
<TD ALIGN='CENTER' VALIGN='MIDDLE' WIDTH='15%'><B>List</B></TD>
</TR>
<!B repeat this block for each record B>
<TR>
<TD ALIGN='LEFT' WIDTH='85%'>
Product Discription goes here
</TD>
<TD ALIGN='CENTER' WIDTH='15%'>
<INPUT TYPE='BUTTON' NAME='Product code goes here'
VALUE='List Products'
ONMOUSEDOWN='parent.ContentFrame.ProdList_OnClick("Product code goes here")'>
</TD>
</TR>
<!B end of repeat block B>
</TABLE>
</FORM></DIV>
</BODY>
</HTML>
The HTML author has produced a nice page that reflects the needed design. From here the extension is changed to .jsp, and now there is a valid JSP page to begin the enhancements. The areas in bold indicate where some Java code would be required.
Before going further, the Java author needs to do some preparatory work by designing the needed Bean that is to be used for the new JSP page.
The SWProductGrpBean
There are a number of ways to tackle the need for repeated records. Each provides a different degree of "intrusion" into the HTML code. At the most intrusive, the entire Java code could be placed within the JSP file. Doing this would largely negate most advantages as well but using the JSP technology, though, there is still a small gain. That gain is all of the "out.printlin(..)" statements that were needed within the servlet. The next level is using JavaBeans and referencing properties and methods in scriptlets inside the HTML document. JavaBeans is better but unless the Java programmer provides clear documentation, this can confuse the HTML designer. The last level is the use of Custom Tags. This provides the HTML designer with "HTML like" tags to place into the HTML document. Tags provide the least intrusive means, but it also requires careful documentation by the Tag designer. By having the HTML be the primary document and keep the intrusion of non-HTML elements, the web page is kept in a much easier design, edit, and alter.
The approach taken in this project will be a middle ground and will depend on the development of a JavaBean that will provide the logic needed. The only Java required within the JSP will be the loop and conditional code, thus keeping the HTML in a much more "undisturbed" state, and therefore much more maintainable for the HTML author who may have no understanding of Java.
The SWProductGrpBean takes the basic code used in the earlier servlet and wraps sections of code within methods that the JSP can call when needed. First, opening and closing a connection to the database is required and provided by: (Code in bold indicates the identical found in the servlet project)
public boolean dbMakeConnect() {
try {
qdsProduct.setQuery(new com.borland.dx.sql.dataset.QueryDescriptor(dbSmiley, "Select * from PRODGRP", null, true, Load.ALL));
dbSmiley.setConnection(new com.borland.dx.sql.dataset.ConnectionDescriptor("jdbc:interbase://localhost/D:\\IBDATA\\SMILEYDB.GDB", "SYSDBA", "masterkey", false, "interbase.interclient.Driver"));
qdsProduct.open();
}
catch (com.borland.dx.dataset.DataSetException dsex) {
dsex.printStackTrace(System.err);
return false;
}
return true;
}
public boolean dbCloseConnect() {
try {
if (qdsProduct == null) {
return false;
}
qdsProduct.close();
dbSmiley.closeConnection();
return true;
}
catch (com.borland.dx.dataset.DataSetException dsex) {
dsex.printStackTrace(System.err);
return false;
}
}
Next is needed a way of moving down the dataset and detecting when the end of the dataset is reached. This is handled with the following two methods:
public boolean dbInBounds() {
try {
if (qdsProduct == null) {
return false;
}
return qdsProduct.inBounds();
}
catch (com.borland.dx.dataset.DataSetException dsex) {
dsex.printStackTrace(System.err);
return false;
}
}
public boolean dbNext() {
try {
if (qdsProduct == null) {
return false;
}
return qdsProduct.next();
}
catch (com.borland.dx.dataset.DataSetException dsex) {
dsex.printStackTrace(System.err);
return false;
}
}
Notice that both here and in the earlier code, everything was wrapped in a try block. Any error would allow the code to exit gracefully.
The last bit of code needed is to retrieve the values from the database. This is handled by a single method that takes the field name of the required column of data.
public String getField(String afieldval) {
try {
if (qdsProduct == null) {
return "ERROR";
}
return qdsProduct.getString(afieldval);
}
catch (com.borland.dx.dataset.DataSetException dsex) {
dsex.printStackTrace(System.err);
return "ERROR";
}
}
JSP Tags - Integrating Java Into HTML
The final step in this process is to add JSP tags to the HTML code that will respond to the JSP engine when it translates the raw JSP into a servlet. The first tag required will be the <jsp:useBean /> tag. It refers to an "id" which is any name desired to reference the bean, and "class" which points the engine to the proper class file. There are a number of other attributes for this tag, as outlined in the reference materials listed in the JSP introduction earlier. The "id" and "class" attributes are the minimum required.
<jsp:useBean id="groupdb" class="swidgetjspbean.SWProductGrpBean" />
Now, using that reference name, the control structure is created to open the database. The scriptlet tag <% %> is used to add two lines of Java code (Java in bold italics for following examples). This code opens the connection and returns a Boolean that will allow the inner code to either run or be skipped entirely.
<% if (groupdb.dbMakeConnect()) { %>
<% } %>
Within this conditional, a "while" loop is added that will check that the dataset cursor has not reached the bottom, and also move the cursor down one record for each loop. Once the code exits the loop the database is disconnected.
<% While (groupdb.dbInBounds()) { %>
<% groupdb.dbNext(); %>
<% } %>
<% groupdb.dbCloseConnect(); %>
The last code is within the while loop and most of this is HTML. The three locations outlined by the HTML author are added with the JSP expression tag <%= %>, which adds the needed values to the HTML document.
<TR>
<TD ALIGN='LEFT' WIDTH='85%'>
<%= groupdb.getField("PROD_GRPDESCRIPT") %>
</TD>
<TD ALIGN='CENTER' WIDTH='15%'>
<INPUT TYPE='BUTTON' NAME='<%= groupdb.getField("PROD_GRP") %>'
VALUE='List Products'
ONMOUSEDOWN='parent.ContentFrame.ProdList_OnClick("
<%= groupdb.getField("PROD_GRP") %>")'>
</TD>
</TR>
Deploying the JavaBean
Before the new JSP page can be tested, the JavaBean must be properly deployed. Different JSP engines require different locations for the deployed .jar file. Borland Application Server (IAS) requires that the .jar file be placed in the \Borland\AppServer\lib directory. To do this, click the "Archive Wizard" in JBuilder and select this path for the output (Figure 10a and 10b). Follow the wizard and the Bean should be properly deployed. Remember to include all dependencies that might not be deployed on the application server or Web Server’s JSP engine.
Figure 10a JBuilder Archive Wizard
Figure 11b JBuilder Archive Wizard
Final Edits to Project
As is so often the case, there are a few small details that cannot be missed before testing the new JSP version of the Product Group Category page. In this case, the only required change is simple and done to the function that calls this page: (Change is in bold)
function Catalog_OnClick() {
parent.MainFrame.document.location = "SWidget_JSP_GrpList.jsp";
}
Now when the button is clicked, it will trigger the new JSP page.
Testing the JSP Page
The first time the page is called there will be a slight delay as the JSP engine translates and complies the JSP code into a servlet. After that first delay all subsequent calls will be very fast, as the code remains loaded and ready. This results in a response that is just as fast as the servlet version.
Unfortunately, the test hardly ever works the first time. Therefore, a way is needed to track down the error messages that come up in the web page, instead of the desired output. BAS places the source .java code into a temporary directory located for this project at:
.\Borland\AppServer\tmpdir\default\pagecompile\jsp\_BC2000\_SWSERVLETJSP\_SWidget__JSP__GrpList.java
This allows the developer the chance to see how the code gets translated into Java, and make sense of any errors that arise in the page compile.
There is a lot more to say about JSP, but this will provide a flavor for the technology and how it fits into the scheme of the web technologies discussed. A number of links are provided to get started on discovering the possibilities for JSP in your next web project.
Accumulative Project Goal Score Card
Final Score Card
The final score card is a bit different than the score cards at the end of each project. This scorecard rates each technology individually, whereas the project score cards rated the entire project for which the feature technology either added or subtracted from that rating. There will be many that could debate my scores "til’ the cows come home", but I offer them simply as a relative measure to provide the reader with a guide, nothing more is intended.
|
Technology |
Goals |
||||||||
|
Deployment |
Zero Install |
Platforms |
Functionality |
Performance |
Stateful |
Presnetation |
Maintenance |
|
|
|
HTML |
9 |
10 |
9 |
0 |
9 |
0 |
10 |
0 |
|
|
JavaScript |
9 |
10 |
8 |
8 |
9 |
1 |
7 |
0 |
|
|
Servlet |
8 |
10 |
10 |
- |
9 |
10 |
10 |
0 |
|
|
XML, XSL, et al. |
9 |
10 |
10 |
9 |
8 |
10 |
5 |
2 |
|
|
JSP |
8 |
10 |
10 |
- |
9 |
10 |
10 |
6 |
|
A lot of ground has been covered, it is hoped that this paper has provided the overview and springboard to bringing these technologies together to solve business requirements. Applets have much to offer. Much of that offering can be provided with the right mix of alternate methods that some of the down side of applets can be overcome, along with some very definite pluses in their own right.
Enjoy!
Appendix A
Applet Design and Deployment
Introduction
The follow appendix is a short version of a presentation given at last year's conference. The full document can be found at this same website page I have included a summarized version here for completeness of this tutorial as reference material.
Applet Design with Deployment in Mind
Simplicity and Minimal classes
Everything MUST go across that wire! Say this to yourself over and over as you design your applet. Make sure your boss/client understands this important fact, and remind them daily. Take into careful consideration the environment in which you intend to deploy this applet. Is it for general public use or Intranet use within a company? What is the connection throughput? What are the features required? What will be the target browser(s) and VM. The bottom line is that whatever you add to this applet will have to be sucked down that wire before your user can even see your applet and users are a very impatient group of people. Try to avoid using a bit of JBCL, a bit of Swing and a bit of some other Bean components from a third party. Each of these groups of classes will bring their own dependencies that will increase the size of your archive file. Lastly, make sure the component actually works in the real world of browsers.
This listboxcontrol works great in the IDE viewer, but fails to function in the browser environment. This same kind of issue can haunt you with layout managers. In the IDE viewer a layout will work just fine. You then deploy the applet, and it can become unusable garbage.
Compatibility to the Lowest JDK Possible
See all those neat JavaBeans on the component pallette? Try and ignore as many of them as possible. Most of them are traps that will consume hours of your time trying to get them to work in an applet. Unless you have time to burn, stick very strictly to the AWT components. As you venture into more database components, stick with one vendor to minimize complex dependencies. (A discussion of different JDK and JFC versions will be found below)
Regular Deployment is Part of the Development Cycle
Deploy often to an environment that will mimic your target environment. This is the key to avoiding painful disappointments after hours of work. As a rule, I will deploy an application after every significant change to the UI or code. This requires that the design equipment often be extensive (see "Hardware needed for proper testing") Though it is possible to test deployment on a single machine in some cases, it often does not address the real issues you may face in the real world, or it may not even be possible. A personal web server often does not mimic a real web server on such things as security issues as they effect databases. For this paper I tried to get all the demos to work on a single machine. It was nothing less than a nightmare. Often times the same applet would work just fine running off a real web server, but would fail on a local environment.
Security Manager, A Major Roadblock.
The Internet depends on security or it would not have grown as fast as it has grown. This is therefore very good. But for many aspects of applet design, and in particular database applet design, it is a roadblock. The Security Manager is responsible for making sure that the visiting applet can do nothing to damage the client's system. Therefore, the Security Manager will place restrictions on the following activities:
The most frustrating part of these restrictions is that they will behave differently on different browsers and between local testing and Internet testing. (Which brings us back to deploy, deploy, deploy while designing.)
Data, Databases and Drivers - The Issues
Trying to design a data centric applet is usually complex and time consuming. Not only does the issue of making database connection cause problems, but the overhead of the data aware components creates its own headaches.
The basic rules of the "SandBox" are that only connections back to the same server are allowed. Any attempt, intentional or otherwise, to make a local connection or a connection to a different server will throw a security exception. The solution is simple but unrealistic; just run your database server on the same machine as the web server.
Since this is generally an untenable solution for most companies, there are fortunately a number of workarounds. One solution is to use a third tier that sits on the server and pretends to be the database connection while the real connection is actually on another machine. This third tier is typically called a "servlet". Another solution is to use a Class 3 driver in which the server for that driver runs on the webserver and talks to the real database that can reside on another machine. Both solutions are basically the same, in that they place middleware on the web server to redirect the database calls to the real database.
To Swing or Not to Swing - The Maze of JDK Versions
When struggling to get an applet to work, one of the most common replies to your cries for help will be something about what version of the JDK you are targeting. I'll try and summarize the basic issues you will face as you decide your target JDK level. (Note: The download links for the JDKs will be found at the end of this paper under "References and Resources")
The Basics - JDK 1.0.2
If you are targeting the most universal use of your applet, this is your target JDK level. This will give you success on most any browser out there today. (I did say "MOST" not "ALL") But sadly, you will be limited to the most primitive of UI and functionality. For practical purposes a database applet at this level is nearly impossible. This is often referred to as JDK 1.0.x in most discussions of earlier JDKs, where 1.0.2 is considered the final version of this line.
A Practical Compromise - JDK 1.1.x
This JDK level (1.1.5 specifically) will work with the latest versions of Netscape and Explorer without any assistance of plugins (which we will get to later) and represents a barely tolerable and practical compromise between function and widespread deployment. The biggest danger here is accidentally using a bean component that needs a significant number of Swing classes, and thereby creating a "mix and match" of JDK versions. In JBuilder2 the JBCL2.0 uses look and feel classes from Swing. The deployment wizard generally does a good job of including the L&F classes, though it is a common error for many. To get full Swing functionality in JDK 1.1.x you need to add JFC 1.1.x (Java Foundation Classes, of which Swing is a significant part. See chart below) You can work around Swing deployment problems by using the swingall.jar file in your deployment, if you don't mind a 15 to 20 minute download before your applet appears. Not a good solution, and it is the typical compromise you will face: function vs. speed. Fortunately, you can use the DataExpress components at this level and it does not add any Swing classes. The NonSwing demos illustrated later in this paper, will demonstrate how much can done in keeping a db applet at this level.
To summarize, this line of JDKs is frequently referred to in the literature as JDK 1.1.x: The JDK 1.1.5 is the last version the will run unassisted in a browser. Adding the JFC ( thru beta 3 version ) will require either deploying swingll.jar (as mentioned above) or the Java Plugin 1.1.1 (beta) or with JFC 1.1 the Java Plugin 1.1.2.
The following table is derived from several sources: in particular...
http://java.sun.com/products/jfc/jaccess-1.2.2/doc/compatibility.html
illustrates some of the relationships between different versions.
|
Java VM / JDK |
Swing release |
|
JDK 1.0x |
No Swing AWT only |
|
JDK 1.1.2 thru 1.1.7 |
JFC 1.1 with Swing 1.0 |
|
JFC 1.1 with Swing 1.0.1 |
|
|
JFC 1.1 with Swing 1.0.3 |
|
|
JFC 1.1 with Swing 1.1 beta |
|
|
JFC 1.1 with Swing 1.1 beta 2 |
|
|
JFC 1.1 with Swing 1.1 beta 3 |
|
|
JFC 1.1 with Swing 1.1 |
|
|
JDK 1.1.8 |
JFC 1.1 with Swing 1.1 |
|
Java Plugin 1.1, 1.1.1 |
JFC thru beta 3 |
|
Java Plugin 1.1.2 |
JFC with Swing 1.1 |
|
JDK 1.2 beta 1, 2, 3 |
bundled Swing |
|
JDK 1.2 beta 4 |
bundled Swing |
|
JDK 1.2 |
bundled Swing |
|
Internet browsers |
JFC 1.1.x (thru 1.1.5) with Swing 1.0 thru 1.1 beta 3 |
If you want to use the last version of this line, download JDK 1.1.8. The early versions of the Plugin (1.1.1 and 1.1.2) can help in Intranet environments to maintain a consistent deployment and behavior, and should be considered. This consistency minimizes the need for testing multiple browsers (See the discussion of Plugins below)
Currently you can only download the JDK 1.0.2 (basic AWT), JDK 1.1.8 plus JFC 1.1, and the current release Java 2 (JDK 1.2) from the main JavaSoft download page (Link found in Resources at the end of this paper)
Browsers support different parts of the Java JDK specifications. The following chart illustrates what is supported by the latest version of Netscape on various platforms. (Note: I was not able to locate a similar chart for MS IExplorer)
|
JDK 1.1 Features |
Win32 |
Win16 |
Mac |
Unix |
|
Internationalization |
X |
X |
X |
X |
|
Networking Enhancements |
X |
X |
X |
X |
|
I/O Enhancements |
X |
X |
X |
X |
|
JAR files |
X |
X |
X |
X |
|
Object Serialization |
X |
X |
X |
X |
|
RMI |
X |
X |
X |
X |
|
Reflection |
X |
X |
X |
X |
|
Inner Classes |
X |
X |
X |
X |
|
JNI- Java Native Interface (see JRI) |
X |
|
|
|
|
Performance Enhancements |
X |
X |
X |
X |
|
Misc. changes - Byte, Short, Void, |
X |
X |
X |
X |
|
AWT 1.1.5 |
X |
|
|
X |
|
New Event Model |
X |
|
|
X |
|
JDBC |
X |
|
|
X |
|
Java Beans |
X |
|
|
X |
|
Printing support |
X |
|
|
X |
(This chart and supporting documentation is found at http://developer.netscape.com/docs/manuals/communicator/javajdk.html)
The Latest and Greatest - Java 2 (JDK 1.2.x)
With this version of the JDK we step into the world of mandatory Plugins. You now can use most all of the components on the JBuilder3 palette. But you pay a very high price for this UI heaven. Yes, the latest plugin will allow you to run these applets, but sadly they have also grown into "megabyte monsters" that take a painfully long time to download. For Intranet use, these work quite well and performance is acceptable. For Internet use, you should still restrain yourself and keep your components simple and basic.
Java Plugins
The discussion on JDKs naturally leads to the topic of Plugins and the what, where, and how of deploying this part of the equation. There are really three versions of the Java Plugin: 1.1.1, 1.1.2 and 1.2.1. The versions 1.1.1 and 1.1.2 are basically the same except for a critical difference. The first version is for the "beta" JFC (1.1 thru beta 3) where the swing components reside in com.sun.java.swing packages. The other (1.1.2) is for the shipping version of the JFC 1.1 classes where the packages were changed to com.sun.javax.swing. As an example of what this means in practical terms, an applet compiled and deployed in JBuilder2 will work using the 1.1.1 plugin, but will throw a verify error in the 1.1.2 plugin unless you separately install the final version of the JFC 1.1. An important note: the link trail to the download page for the 1.1.1 version appears to be no longer active, even though the download page is still in existence (Sun is hiding it because they want you to use the 1.1.2 version) The link to this page is included below in the "Resources" section of this paper.
Installation of the Plugin
The Java Plugin must be installed on every client. You can see the problem already, as this is exactly the reason for using applets; to avoid this very issue. Fortunately this can be done "dynamically" from your webpage that embeds your applet. If the HTML code for your "plugin applet" was configured correctly (See HTML Converter below) the web browser will notify the client that they need a plugin, and the install process can be done by each client on a "one time" basis. Netscape and MS IExplorer each handle this differently. IExplorer is by far the best and most user friendly installation. Netscape requires the user to click the download, decide where to download the file, then run the install, whereas Explore handles it all for you with some basic wizards that require nothing more from the user than to click a few buttons.
You, as a developer, can just go to the Java Plugin link provided below and install the plugin directly. The plugin magically becomes available to both Netscape and IExplore
HTML Converter
The HTMLConverter is a small utility provided by Sun that converts any applet tag to a Java Plugin tag. This is very handy and allows you to avoid reading and understanding the twenty page document that explains what this utility does for you. Having said that, even if you use the converter, do read the document, as it does help explain what all that stuff it inserts into your html document means and how it works. (See the Java Download Page link in the Resources section for a link to the HTMLConverter.) There are two converters: one for the 1.1.x plugin and one for the 1.2.x plugin. The results are identical with one exception; they each point to a different download page for the client to download the proper plugin. Therefore, make sure you use the correct converter or your clients will be downloading the wrong plugin and nothing will work.
A few Plugin GotCha's
Unfortunately, if you are a developer and find yourself working with both plugins (as I have to) you can not run both at the same time. You will find yourself doing a lot of "uninstall/install". When trying to run the 1.2.x converter, you will find it does not work if you follow Sun's directions to the letter. (Note: Earlier versions of the HTMLConverter used an exe to start the java converter. Apparently Sun decided with the latest version to be a "purist" and only supply the classes and leave you to figure out how to run a java app in Windows) What is missing is a "." (period) in your class path. To solve the problem, edit the classpath setting in your environment to look something like:
ClassPath=.;f:\Interclient\interclient.jar;..etc...
where the semi-colon ";" is added to the beginning of your current classpath assignment.
To setup a shortcut to run the 1.2.x HTMLConverter, use the following settings which you should alter to match your specific locations for these files.
Target: F:\JBuilder3\java\bin\java.exe HTMLConverter
Start In: F:\JavaPlugin12
Deployment Scenarios
Hardware Needed for Proper Testing
In general it is easier to deploy an applet on a "real" web server configuration than on a "one machine does everything" configuration. Whenever possible opt for setting up a real server with the same web server software you intend to use in production. If a database enters into the picture, again mimic the real target environment. If it is one of those very rare situations where the webserver and the database server are one and the same, then you can get away with two machines. Otherwise, don't skimp as you will suddenly be faced with issues during deployment that were not completely tested. You may end up with mud on your face.
The ideal minimum system is four machines: A web server, a database server, a testing client running a browser, and a dev machine running Jbuilder. The cost of the extra machines will be quickly paid for after it is realized how time consuming it is to switch between each, trying to keep everything straight as to what is really happening and why.
Basic Applet Deployment Steps
The basics on deployment can be found in the help files and on information found on the Borland.com website. The following summarizes this information with additional comments from my own experience and others.
1. Add all the files you use for your project using the Add to Project button on the AppBrowser. This includes resource files (such as images or audio), documentation files (.txt or .html), and classes that are referenced using Class.byName or Beans.instantiate.
2. Use the Resource Strings Wizard to move your strings to a resource bundle. This is optional, but makes it easier to localize your applet for a different Locale.
3. Compile the applet. (Make sure you save it first. This does make a difference). I have also noticed that if you have made changes to a class file and it does not appear to Atake@, that you will need to exit JBuilder and restart. Recompile one more time before running the Deployment Wizard. This has occurred with changes to driver and URL names.
4. Use the Deployment Wizard to create a Java archive. The .html files should be unselected when you deploy the main zip or jar file. Run the deployment wizard again and only select the html and check Ano archive@ to move this file to the target location.
Important: Including the JBCL image resources in a stand-alone archive is critical for applets that use JBCL controls. Extract the images from the JBuilder archive and add them to yours, preserving their case and location. (Extract them to the root directory, and your zip tool will capture the whole path and case structure for you, removing the root directory name.)
5. Copy the archive created in Step 4, or all the compiled Java, image, and multimedia files used by your applet (or the archive you created in Step 4) to the target server. It is better to send the output of the Deployment Wizard directly to the target directory.
6. Ensure that the HTML applet tags which start your application will work from within the server's directory structure, and that the CODEBASE, CODE and ARCHIVE tags are all assigned correctly.
CODEBASE as a parameter to the APPLET tag is really misunderstood. It basically states where /dev/home/myapp/files/web/java would be stored in:
/dev/home/myapp/files/web/java/borland/jbcl/control/GridView.class.
Note: Your archives do not have to be in the CODEBASE directory if you use a relative directory to point at the archive, one that is relative to the CODEBASE directory. If you just specify the file without any directory, then it does need to be in the CODEBASE directory. CODEBASE set to " ", ".", or "./" means "current directory" relative to the HTML file. If this is what you mean, then you can skip the CODEBASE parameter entirely. (Warning! Different web servers appear to interpret the CODEBASE differently. Test it first.)
7. Copy the HTML files containing the applet tags to the server. Again, you can do this with the Deployment Wizard by only selecting the .html file and checking "no Archive". Then set the output directory to your root web directory.
8. Optional: If users need to have certain Java classes or archives already installed on their machine, you may need to provide a convenient means for them to download those files and add them to their local CLASSPATH.
Local Testing Issues
The biggest issue with testing locally is the tendency for your applet to try and load class files via the local Classpath. The only way to avoid this is to remove all classpaths from your environment while testing on a local webserver
A Simple Applet
It is always good to start of with a simple case to illustrate the core steps in deployment. This applet is so simple it may give you a false sense of success. Be forewarned: it gets much harder, but the basic steps will be the same. Up to this point in this paper, the theory and basic preliminary setup information have been provided. Now that knowledge must come to bear on the real struggle of deploying a real applet. Hold on to your seats!
Applet Design
Design a very basic applet with two text fields, a button, and associated labels. ONLY use AWT components.
Deployment
The first step in deployment is to follow the basic steps outlined in the previous section. Then attempt to load your html page via a webserver. Using the Personal Web server, your URL might look like;
Ahttp://127.0.0.1/basicapplet.html@
If this returns an error or does not load, then some investigation is required. NoDefClassNotFound is one of the most common errors, and means that either the deployment was incomplete, or some other problem that is being hidden by this error. The next step is to attempt to run your applet in the applet viewer.
The AppletViewer Test
Step 1 - Nuke the ClassPath - This requires a minimal classpath be defined in your environment. (This effectively eliminates the classpath. Remember browsers don=t have classpaths.)
Aset classpath= @
Step2 - Gather the Pieces - The next step is to get the HTML document and the zip or jar file that you deployed into the same directory along with a copy of the appletviewer (found in the \Jbuilder\java\bin directory)
Step 3 - Test it - Then run the applet with the following command line at the console commandline from the root HTML directory. Typically, Jbuilder places the HTML document in the "myclasses" subdirectory. Therefore, that should be where you test the applet in this example.
AppletViewer BasicApplet.html
Step 4 - Don't Panic - If it does not run correctly in this environment, it is then clear that something is being either deployed incorrectly/incompletely, the html codebase is wrong, the applet tag is wrong, you followed the directions wrong, or it simply is not your day (an amazingly common problem). Review all the steps outlined above. Often it is the simplest of things that get missed.
References and Resources
Rich Wilkman=s AThe Java Curmudgeon@
http://we.got.net/~rwilkman/java/index.html
Suns Applet Page
http://java.sun.com/applets/index.html
Java Plugin pages
MainPage http://java.sun.com/products/plugin/index.html
Plugin1.1.1 http://java.sun.com/products/plugin/1.1.1/plugin-install.html
Java Download Page
http://java.sun.com/cgi-bin/download2.cgi
Inprise Tech Documents on Deployment
http://www.inprise.com/jbuilder/papers/techdoc/index.html
Applet Security
http://java.sun.com/security/codesign/
Jbuilder Technical Papers
http://www.borland.com/jbuilder/papers
Appendix B
Servlet Engines
this is 100% Pure Java webserver that includes servlet support directly. Unfortunately this product is to be discontinued, and replaced by the Sub/Netscape iPlanet servers (you can download a free trial from the Netscape web site). The iPlanet server also supports servlets directly.
This is the completely open-source approach, and it will run on several different platforms. I have seen in this forum that many people use this setup as their development platforms. JServ is to replaced soon by Jakarta, which will provide the reference implementations of the Servlet API and the JavaServerPages specification (http://jakarta.apache.org).
This is a server add-on product that supports lots of different web servers and platforms. The product itself is not bad, but the documentation needs a lot of work. You can download a version for development and non-commercial use from Allaire's web-site, however, commercial use costs something in the order of $US600 per CPU.
Servlet support is also built into most of the application servers out there on the market. I believe also that the Lotus Domino Go webserver supports servlets directly as well.
Appendix C
A Question of Framing
A quick discussion on the use of frames in website design might be usesful. Frames can be annoying when the website you are using insists on showing all links "in" their frames. Many sites solve this by using the Javascript method open() to open the link in a new window. I would strongly encourage this practice. As a rule I only keep "my" site windows in the frameset. Frames can be simulated using tables to created the "regions" for different types of information. The downside of working with " pages" is that the entire page must be refreshed. For database work this can be a real performance drain. Because of this, when I have a lot of callbacks to servlets to display changes, I prefer frames. In this way only the region that is changing gets refreshed.
Appendix D
XML Tags Primer
XML is an extension of SGML which is also the basis for HTML. Not surprisingly, XML and HTML look very much alike. The key difference is that HTML has fixed and standardized tags, whereas XML is designed to allow the author to self define tags and their meanings, either as a separate DTD (Document Tag Definition) document or embedded within the XML document itself. Standard parsers are available in most languages that will validate XML based on a given DTD, as well as extractors (see SAX in Appendix E), that allow efficient extraction of data from an XML.
At the simplest level a given tag defines a "block" that resides between the opening and closing tags. The closing tag has the same name with the addition of a back-slash. You can also have self-closing tags in which the tag ends with a back-slash. Within a given tag there can be sub-tags that define elements within the main tag. Sub-tags can have their own sub-tags, and so on, as far as needed.
Next, a given tag can have attributes that are defined within the opening tag as name=value pairs. These are generally attributes that define a global property of what that tag is representing.
As a simple example, an XML tag schema is developed below to illustrate the basics just discussed. A full discussion of DTD , DOM, and tag component structure and development is beyond the scope of this paper. For this example we will play it loose, and just outline what we need to express as a simple table of data. Following, is a brief description of the tag scheme developed that is used in the project for this paper.
Request Tags
Our request tag needs the ability to send a simple query to the servlet for data. It therefore needs to provide a table name, a list of requested fields, a where clause, and a count of records requested.
<REQUEST></REQUEST>
<QUERYDATA table=@A fields=@A where=@A returncnt=0></QUERYDATA>
</QUERYDATA>
A basic request might look like:
<REQUEST>
<QUERYDATA table="Product" fields="PROD_CODE,PROD_DESCRIPT" where="PRO_PAR < 1.00" returncnt=50></QUERYDATA>
</REQUEST>
<MetaData table="" fields=""/>
A basic request might look like:
<REQUEST>
<METADATA table="Product" fields="PROD_CODE,PROD_DESCRIPT"/>
</REQUEST>
Reponse Tags
<RESPONSE></RESPONSE>
<DATATABLE tblname="" rowid="" morerecords="true"></DATATABLE>
<TROW></TROW>
<TFIELD colname="" visible=true datatype="" width="">value<TFIELD>
A basic table response might look like:
<RESPONSE>
<DATATABLE tblname="Product" rowid="PROD_CODE" morerecords="true">
<TROW>
<TFIELD colname="PROD_CODE" datatype="varchar10">16901</TBLFIELD>
<TFIELD colname="PROD_DESCRIPT" datatype="varchar20">Static Cling Decal</TBLFIELD>
</TROW>
<TROW>
<TFIELD colname="PROD_CODE" datatype="varchar10">BS1S</TBLFIELD>
<TFIELD colname="PROD_DESCRIPT" datatype="varchar20">Bumper Sticker</TBLFIELD>
</TROW>
<TROW>
<TFIELD colname="PROD_CODE" datatype="varchar10">DSBA</TBLFIELD>
<TFIELD colname="PROD_DESCRIPT" datatype="varchar20">Assorted Sports Btls</TBLFIELD>
</TROW>
</DATATABLE>
</RESPONSE>
<METADATA table="" columncount=0 rowid=""> </METADATA>
<COLUMN name="" columnwidth=0 columndatatype="" columncaption=""/>
A basic response might look like:
<RESPONSE>
<METADATA table="Product", columncount=2 rowid="PROD_CODE">
<COLUMN name="PROD_CODE" columnwidth=10 columndatatype="varchar" columncaption="Product Code"/>
<COLUMN name="PROD_DESCRIPT" columnwidth=20 columndatatype="varchar" columncaption="Description"/>
</METADATA>
</RESPONSE>
Appendex E
SAX - Simple API for XML
There are a number of methods by which information can be extracted from an XML string. SAX provides a lightweight, event-driven mechanism. Setting up SAX involves several steps that I will outline here. You should consult a good XML book for a more detailed discussion. The purpose of this appendix is to provide you with a quick overview of the process so that the discussion on XML makes a bit more sense.
Implement a DocumentHandler or extend a HandlerBase
The DocumentHandler requires that you implement a number of methods that will be triggered by the parser. These events will allow you to extract information during the parse. The basic methods you need to implement are:
By their names, you can guess fairly well their purpose. In addition to implementing all of the methods, you can extend the adapter class HandleBase, and using that, can override only those methods you need. This would be useful if you only need one or two methods.