Document object model

If NN and IE are close in core JavaScript language compatibility, nothing could be further from the truth when it comes to the document objects. Internet Explorer 3 based its document object model (DOM) on that of Netscape Navigator 2, the same browser level it used as a model for the core language. When Netscape added a couple of new objects to the model in Navigator 3, the addition caused further headaches for neophyte scripters who expected those objects to appear in Internet Explorer 3. Probably the most commonly missed object in Internet Explorer 3 was the image object, which lets scripts swap the image when a user rolls the cursor atop a graphic—mouse rollovers, they’re commonly called.

In the Level 4 browsers, however, Internet Explorer’s document object model jumped way ahead of the object model Netscape implemented in Navigator 4. The two most revolutionary aspects of IE4 were the ability to script virtually every element in an HTML document and the instant reflow of a page when the content changed. This opened the way for HTML content to be genuinely dynamic without requiring the browser to fetch a rearranged page from the server. NN4 implemented only a small portion of this dynamism, without exposing all elements to scripts or reflowing the page. Inline content could not change as it could in IE4. Suffice it to say IE4 was an enviable implementation.

At the same time, a DOM standard was being negotiated under the auspices of the World Wide Web Consortium (W3C). The hope among scripters was that once a standard was in place, it would be easier to develop dynamic content for all browsers that supported the standard.

Netscape took this wish to heart and designed an almost entirely new browser: Navigator 6. It incorporates all of the W3C DOM Level 1 and a good chunk of Level 2. Even though Microsoft participated in the W3C DOM standards development, IE5 implements only some of the W3C DOM standard—in some cases, just enough to allow cross-browser scripting that adheres to the standard. Of course, the standard is not perfect either, and it brings to the DOM several brand-new concepts for scripters. When you take these issues into account, and add to the mix the number of older browsers still in use, scripting HTML objects is touchy business. It requires a good knowledge of compatibility, as described in the object discussions throughout this book.

Core language standard

Keeping track of JavaScript language versions requires study of history and politics. History covers the three versions developed by Netscape; politics covers Microsoft’s versions and the joint standards effort. The first version of JavaScript (in Navigator 2) was Version 1.0, although that numbering was not part of the language usage. JavaScript was JavaScript. Version numbering became an issue when Navigator 3 was released. The version of JavaScript associated with that Navigator version was JavaScript 1.1. As you will learn later in this book, the version number is sometimes necessary in an attribute of the HTML tags that surround a script. The Navigator 4.x generation increased the language version one more notch with JavaScript 1.2.

Microsoft’s scripting effort contributes confusion for scripting newcomers. The first version of Internet Explorer to include scripting was Internet Explorer 3. The timing of Internet Explorer 3 was roughly coincidental to Navigator 3. But as scripters soon discovered, Microsoft’s scripting effort was one generation behind. Microsoft did not license the JavaScript name. As a result, the company called its language JScript. Even so, the HTML tag attribute that requires naming the language of the script inside the tags could be either JScript or JavaScript for Internet Explorer. Internet Explorer 3 could understand a JavaScript script written for Navigator 2.

During this period of dominance by Navigator 3 and Internet Explorer 3, scripting newcomers were often confused because they expected the scripting languages to be the same. Unfortunately for the scripters, there were language features in JavaScript 1.1 that were not available in the older JavaScript version in Internet Explorer 3. Microsoft improved JavaScript in IE3 with an upgrade to the .dll file that gives IE its JavaScript syntax. However, it’s hard to know which .dll is installed in any given visitor’s IE3. The situation smoothed out for Internet Explorer 4. Its core language was essentially up to the level of JavaScript 1.2 in Navigator 4. Microsoft still officially called the language JScript. Almost all language features that were new in Navigator 4 (including the script tag attribute identifying JavaScript 1.2) were understood when you loaded the scripts into Internet Explorer 4.

While all of this jockeying for JavaScript versions was happening, Netscape, Microsoft, and other concerned parties met to establish a core language standard. The standards body is a Switzerland-based organization originally called the European Computer Manufacturer’s Association and now known simply as ECMA (commonly pronounced ECK-ma). In mid-1997, the first formal language specification was agreed on and published (ECMA-262). Due to licensing issues with the JavaScript name, the body created a new name for the language: ECMAScript. With only minor and esoteric differences, this first version of ECMAScript was essentially the same as JavaScript 1.1 found in Navigator 3. Both Navigator 4 and Internet Explorer 4 supported the ECMAScript standard. Moreover, as happens so often when commerce meets standards bodies, both browsers went beyond the ECMAScript standard. Fortunately, the common denominator of this extended core language is broad, lessening authoring headaches on this front.

IE5 advances to JavaScript version 1.3, while NN6 has the luxury of implementing JavaScript 1.5. In the meantime, the ECMA standard has evolved to a new release that incorporates features found in JavaScript 1.3 and 1.5. While the core language tends to exhibit the most compatibility between IE and

NN, authors must pay attention to which language features are available in the browsers visiting scripted pages. Older browser versions are not equipped to handle newer JavaScript features. But you can sometimes script around these incompatibilities (as described throughout the language reference in Part IV).

JavaScript: The Right Tool for the Right Job

Knowing how to match an authoring tool to a solution-building task is an important part of being a well-rounded Web page author. A Web page designer who ignores JavaScript is akin to a plumber who bruises his knuckles by using pliers instead of the wrench at the bottom of the toolbox.

By the same token, JavaScript won’t fulfill every dream. The more you understand about JavaScript’s intentions and limitations, the more likely you will be to turn to it immediately when it is the proper tool. In particular, look to JavaScript for the following kinds of solutions:

✦ Getting your Web page to respond or react directly to user interaction with form elements (input fields, text areas, buttons, radio buttons, checkboxes, selection lists) and hypertext links—a class of application I call the serverless CGI

✦ Distributing small collections of database-like information and providing a friendly interface to that data

✦ Controlling multiple-frame navigation, plug-ins, or Java applets based on user choices in the HTML document

✦ Preprocessing data on the client before submission to a server

✦ Changing content and styles in modern browsers dynamically and instantly in response to user interaction

At the same time, understanding what JavaScript is not capable of doing is vital. Scripters waste many hours looking for ways of carrying out tasks for which JavaScript was not designed. Most of the limitations are designed to protect visitors from invasions of privacy or unauthorized access to their desktop computers.

Therefore, unless a visitor uses a modern browser and explicitly gives you permission to access protected parts of his or her computer, JavaScript cannot surreptitiously perform any of the following actions:

✦ Setting or retrieving the browser’s preferences settings, main window appearance features, action buttons, and printing

✦ Launching an application on the client computer

✦ Reading or writing files or directories on the client or server computer

✦ Capturing live data streams from the server for retransmission

✦ Sending secret e-mails from Web site visitors to you

Web site authors are constantly seeking tools that will make their sites engaging (if not “cool”) with the least amount of effort. This is particularly true when the task is in the hands of people more comfortable with writing, graphic design, and page layout than with hard-core programming. Not every Webmaster has legions of experienced programmers on hand to whip up some special, custom enhancement for the site. Nor does every Web author have control over the Web server that physically

houses the collection of HTML and graphics files. JavaScript brings programming power within reach of anyone familiar with HTML, even when the server is a black box at the other end of a telephone line.

LiveScript becomes JavaScript

In early December 1995, just prior to the formal release of Navigator 2, Netscape and Sun jointly announced that the scripting language thereafter would be known as JavaScript. Though Netscape had several good marketing reasons for adopting this name, the changeover may have contributed more confusion to both the Java and HTML scripting worlds than anyone expected.

Before the announcement, the language was already related to Java in some ways. Many of the basic syntax elements of the scripting language were reminiscent of the C and C++ style of Java. For client-side scripting, the language was intended for very different purposes than Java—essentially to function as a programming language integrated into HTML documents rather than as a language for writing applets that occupy a fixed rectangular area on the page (and that are oblivious to anything else on the page). Instead of Java’s full-blown programming language vocabulary (and conceptually more difficult to learn object-oriented approach), JavaScript had a small vocabulary and a more easily digestible programming model.

The true difficulty, it turned out, was making the distinction between Java and JavaScript clear to the world. Many computer journalists made major blunders when they said or implied that JavaScript provided a simpler way of building Java applets. To this day, many programmers believe JavaScript is synonymous with the Java language: They post Java queries to JavaScript-specific Internet newsgroups and mailing lists.

The fact remains today that Java and JavaScript are more different than they are similar. The two languages employ entirely different interpreter engines to execute their lines of code. Whereas JavaScript support shipped in every platform-specific version of Navigator 2 in February 1996, Java was not available for Windows 3.1 users until late in the life of Navigator 3. (Many squirrelly technical issues make it difficult for this modern language to work in an “ancient” MS-DOS operating system.)

JavaScript: A Language for All

The Java language is derived from C and C++, but it is a distinct language. Its main audience is the experienced programmer. That leaves out many Web page authors. I was dismayed at this situation when I first read about Java’s specifications.

I would have preferred a language that casual programmers and scripters who were comfortable with authoring tools such as Apple’s once-formidable HyperCard and Microsoft’s Visual Basic could adopt quickly. As these accessible development platforms have shown, nonprofessional authors can dream up many creative applications, often for very specific tasks that no professional programmer would have the inclination to work on. Personal needs often drive development in the classroom, office, den, or garage. But Java was not going to be that kind of inclusive language.

My spirits lifted several months later, in November 1995, when I heard of a scripting language project brewing at Netscape. Initially born under the name LiveScript, this language was developed in parallel with Netscape’s Web server software. The language was to serve two purposes with the same syntax. One purpose was as a scripting language that Web server administrators could use to manage the server and connect its pages to other services, such as back-end databases and search engines for users looking up information. Extending the “Live” brand name further, Netscape assigned the name LiveWire to the database connectivity usage of JavaScript on the server.

On the client side—in HTML documents—authors could employ scripts written in this new language to enhance Web pages in a number of ways. For example, an author could use LiveScript to make sure that the information a user enters into a form is of the proper type. Instead of forcing the server or database to do the data validation (requiring data exchanges between the client browser and the server), the user’s computer handles all the calculation work—putting some of that otherwise wasted horsepower to work. In essence, LiveScript could provide HTML-level interaction for the user.

As the intensity of industry interest in Java grew, Netscape saw another opportunity for LiveScript: as a way for HTML documents (and their users) to communicate with Java applets. For example, a user might make some preference selections from checkboxes and pop-up selection lists located at the top of a Web page. Scrolling down to the next screenful, the user sees text in the Java applet scrolling banner on the page that is customized to the settings made above. In this case, the LiveScript script sends the text that is to appear in the scrolling banner to the applet (and perhaps a new color to use for the banner’s background and text). While this is happening, the server doesn’t have to worry a bit about it, and the user hasn’t had to wait for communication between the browser and the server. As great an idea as this was initially, this connectivity feature didn’t make it into Navigator 2 when JavaScript first became available.

Java Applets

When the interaction between user and Web page exceeds the capabilities of HTML, experienced programmers may prefer to “roll their own” programs to handle the special needs not available in existing plug-ins. The Java programming language fills this need. Developed by Sun Microsystems, this language enables programmers to write small applications (applets) that download to the browser as separate files.

An applet runs as the user needs it and then is automatically discarded from memory when the user moves elsewhere in the Web. Animation, including animated text whose content can change over time, is a popular application of the Java applet in an HTML page. Because applets can also communicate with the Internet as they run (it is a very network-centric programming language), they are also used for real-time, data-streaming applications that display up-to-the-minute news, stock market, and sports data as this information comes across the wires. Standard HTML content can surround all of this activity as the Web page designer sees fit.

To play a Java applet, a browser company must license the technology from Sun and build it into its browser (or link up with a Java engine that is part of the operating system). Netscape was the first third-party browser supplier to license and produce a browser capable of running Java applets (Navigator 2 under Windows 95 and UNIX). Today, both Netscape Navigator and Microsoft Internet Explorer (IE) can load and run Java applets on almost every operating system platform supported by the browser.

Despite a flash of popularity in the early Java days, Java is used less and less for browser applets. It is quite popular, however, on the server, where it is used frequently to create small server application modules called servlets. On the client, Java applets suffer the same problem as some plug-ins: the delay required to download the file. Also, not every browser is equipped with the desired Java component, causing potential compatibility conflicts.

CGI Scripting

One way to enhance the interaction between user and content is to have the page communicate with the Web server that houses the Web pages. Popular Web search sites, such as Yahoo!, Google, and Lycos, enable users to type search criteria and click a button or two to specify the way the search engine should treat the query.

E-commerce sites enable you to gather products in a virtual shopping cart and then click a button to submit an order for processing. When you click the Submit or Search buttons, your browser sends your entries from a form to the server. On the server, a program known as a CGI (Common Gateway Interface) script formats the data you enter and sends this information to a database or other program running on the server. The CGI script then sends the results to your browser, sometimes in the form of a new page or as information occupying other fields in the form.

Writing customized CGI scripts typically requires considerable programming skill. Most CGI scripts are written in languages such as Perl, Java, and C or C++. Very few servers are equipped to run server scripts written in JavaScript. Whatever language you use, the job definitely requires the Web page author to be in control of the server, including whatever back-end programs (such as databases) are needed to supply results or massage the information coming from the user. Even with the new, server-based Web site design tools available, CGI scripting often is not a task that a content-oriented HTML author can do without handing it off to a more experienced programmer.

As interesting and useful as CGI scripting is, it burdens the server with the job of processing queries. A busy server may process hundreds of CGI scripts at a time, while the client computers—the personal computers running the browsers—sit idle as the browser’s logo icon dances its little animation. This wastes desktop processing horsepower, especially if the process running on the server doesn’t need to access big databases or other external computers. That’s why some people regard browsing a basic Web page as little more than using a dumb terminal to access some server content.

Hypertext Markup Language (HTML)

As an outgrowth of SGML (Standard Generalized Markup Language), HTML is generally viewed as nothing more than a document formatting, or tagging, language. The tags (inside <> delimiter characters) instruct a viewer program (the browser or, more generically, the client) how to display chunks of text or images.

Relegating HTML to the category of a tagging language does disservice not only to the effort that goes into fashioning a first-rate Web page, but also to the way users interact with the pages. To my way of thinking, any collection of commands and other syntax that directs the way users interact with digital information is programming.

With HTML, a Web page author controls the user experience with the content just as the engineers who program Microsoft Excel craft the way users interact with spreadsheet content and functions. Recent enhancements to the published standards for HTML (HTML 4.0 and later) endeavor to define more narrowly the purpose of HTML to assign context to content, leaving the appearance to a separate standard for style sheets. In other words, it’s not HTML’s role to signify that some text is italic, but rather to signify why it is italic. (For example, you tag a chunk of text that conveys emphasis regardless of how the style sheet or browser sets the appearance of that emphasized text.) The most interactivity that HTML lets authors play with is associated with fill-in-the-blank forms. Browsers display text boxes, radio buttons, checkboxes, and select lists in response to HTML tags for those types of form controls. But that’s as far as HTML goes. Any processing of the choices or information entered into the form by the user is the job of other technologies, such as programs on the server or client-side scripts.

Competition on the Web

Web page publishers revel in logging as many visits to their sites as possible. Regardless of the questionable accuracy of Web page hit counts, a site consistently logging 10,000 dubious hits per week is clearly far more popular than one with 1,000 dubious hits per week. Even if the precise number is unknown, relative popularity is a valuable measure. Encouraging people to visit a site frequently is the Holy Grail of Web publishing.

Competition for viewers is enormous. Not only is the Web like a ten million-channel television, but the Web competes for viewers’ attention with all kinds of computergenerated information. That includes anything that appears onscreen as interactive multimedia. Users of entertainment programs, multimedia encyclopedias, and other colorful, engaging, and mouse finger-numbing actions are accustomed to high-quality presentations. Frequently, these programs sport first-rate graphics, animation, liveaction video, and synchronized sound. In contrast, the lowest common denominator Web page has little in the way of razzle-dazzle. Even with the help of recent advances in Dynamic HTML and style sheets, the layout of pictures and text is highly constrained compared with the kinds of desktop publishing documents you see all the time. Regardless of the quality of its content, a vanilla HTML document is flat. At best, interaction is limited to whatever navigation the author offers in the way of hypertext links or forms whose filled-in content magically disappears into the Web site’s server.

With so many ways to spice up Web sites and pages, you can count on competitors for your site’s visitors to do their darndest to make their sites more engaging than yours. Unless you are the sole purveyor of information that is in high demand, you continually must devise ways to keep your visitors coming back and entice new ones. If you design an intranet, your competition is the drive for improved productivity by the colleagues who use the internal Web sites for getting their jobs done. These are all excellent reasons why you should care about using one or more Web technologies to raise your pages above the noise. Let’s look at the major technologies you should know about.

JavaScript’s Role in the World Wide Web and Beyond

Many of the technologies that make the World Wide Web possible have far exceeded their original visions. Envisioned at the outset as a medium for publishing static text and image content across a network, the Web is forever being probed, pushed, and pulled by content authors. By taking for granted so much of the “dirty work” of establishing the connection and conveying the bits between server and client computers, content developers and programmers dream of using that connection to generate new user experiences and operating system-independent applications. A developer community essentially taking ownership of a technology and molding it to do new and exciting things is not new. It’s the enormous popularity of the Web and the accessibility of the technologies to everyday folks who have intriguing ideas that has led to an unprecedented explosion in turning the World Wide Web from a bland publishing medium into a highly interactive, operating system-agnostic authoring platform.

The JavaScript language is a Web-enhancing technology. When employed on the client computer, the language can help turn a static page of content into an engaging, interactive, and intelligent experience. Applications can be as subtle as welcoming a site’s visitor with the greeting “Good morning!” when it is morning in the client computer’s time zone—even though it is dinnertime where the server is located. Or applications can be much more obvious, such as delivering the content of a slide show in one-page download while JavaScript controls the sequence of hiding, showing, and “flying slide” transitions while navigating through the presentation. Of course, JavaScript is not the only technology that can give life to drab Web content. Therefore, it is important to understand where JavaScript fits within the array of standards, tools, and other technologies at your disposal. The alternative technologies described in this chapter are HTML, server programs, plug-ins, and Java applets. In most cases, JavaScript can work side by side with these other technologies, even though the hype around some make them sound like one-stop shopping places for all your interactive needs. That’s rarely the case. Finally, you learn about the origins of JavaScript and what role it plays in today’s advanced Web browsers.

how to got execution time?

if you want to got the execution time of the process you can insert this code to your program
System.out.println(System.currentTimeMillis());
the value you got from this method are long variable.
if you want know how much time that the program you make it doing the process, you can insert " System.out.println(System.currentTimeMillis()); " before the process and after the process, after that calculate the number that you got after process minus the number you got before process.
some how the values can be the same from 1 process into another process, if that happen. the process you got is very fast.
oh i forgot, the values you got is in milisecond, if you want got how many second you can "/1000".

Limit a TextField to Uppercase

import java.awt.*;
import java.awt.event.*;
public class UpperTF extends Frame {
public static void main(String argv[]) {
new UpperTF().setVisible(true);
}
public UpperTF() {
setLayout(new FlowLayout());
TextField tf = new TextField(10);
add(tf);
tf.addKeyListener( new KeyAdapter() {
public void keyPressed(KeyEvent e) {
if (Character.isLetter(e.getKeyChar())) e.setModifiers(Event.SHIFT_MASK); } });
pack();
addWindowListener( new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.exit(0);
} } ); }
public Dimension getPreferredSize() {
return new Dimension(200,200);
}}