Professional Documents
Culture Documents
Host Objects : Browsers and the DOM-Introduction to the Document Object Model DOM History
and Levels-Intrinsic Event Handling-Modifying Element Style-The Document Tree-DOM Event
Handling-Accommodating Noncompliant Browsers Properties of window-Case Study. Server-Side
Programming: Java Servlets- Architecture -Overview-A Servelet-Generating Dynamic Content-Life
Cycle- Parameter Data-Sessions-Cookies- URL Rewriting-Other Capabilities-Data Storage Servlets
and Concurrency-Case Study-Related Technologies.
Introduction:
The Document Object Model is a platform- and language-neutral interface that will allow programs
and scripts to dynamically access and update the content, structure and style of documents.
When we see a document using a browser, DOM presents documents as a hierarchy of HTML or
XML objects in the document. This hierarchy structure makes it possible for programmers or
browsers to access and delete, add, or edit their content, attributes and style.
The DOM makes it possible for programmers to write applications which work properly on all
browsers and servers and on all platforms.
What is DOM?
The DOM defines a standard for accessing documents like XML and HTML:
"The W3C Document Object Model (DOM) is a platform and language-neutral interface that allows
programs and scripts to dynamically access and update the content, structure, and style of a
document."
The DOM originated as a specification to allow JavaScript scripts and Java programs to be
portable among Web browsers.
"Dynamic HTML" was the immediate ancestor of the Document Object Model, and it was
originally thought of largely in terms of browsers.
However, when the DOM Working Group was formed at W3C, it was also joined by vendors
in other domains, including HTML or XML editors and document repositories.
Several of these vendors had worked with SGML before XML was developed; as a result, the
DOM has been influenced by SGML Groves and the HyTime standard.
Some of these vendors had also developed their own object models for documents in order to
provide an API for SGML/XML editors or document repositories, and these object models have also
influenced the DOM.
The World Wide Web Consortium (W3C) developed the W3C Document Obeject Model in
response to the development of various proprietary models for HTML, particularly those used in
Web Browsers.
W3C began development of the DOM in mid-1990s. Although the W3C never produced a
specification for DOM 0, it was nonetheless a partially documented model and was included in the
specification of HTML4. By October 1998, the first specification of DOM (DOM 1) was released.
DOM 2 was issued in November 2000, with specifics on the style sheet object model and
style information manipulation. DOM 3 was released in April 2004 and is the current release of the
DOM specification.
Levels of DOM
The W3C DOM specifications are divided into levels, each of which contains required and
optional modules.
To claim to support a level, an application must implement all the requirements of the
claimed level and levels below it. As of 2005, Level 1, Level 2, and some modules of Level 3 are
W3C Recommendations which means they have reached their final form.
DOM Level 1 Specifications
Document Object Model Level 1 is a platform- and language-neutral interface that allows
programs and scripts to dynamically access and update the content, structure and style of documents.
The Document Object Model provides a standard set of objects for representing HTML and
XML documents, a standard model of how these objects can be combined, and a standard interface
for accessing and manipulating them.
Vendors can support the DOM as an interface to their proprietary data structures and APIs,
and content authors can write to the standard DOM interfaces rather than product-specific APIs, thus
increasing interoperability on the Web.
The goal of the DOM specification is to define a programmatic interface for XML and
HTML.
The Core DOM Level 1 section provides a low-level set of fundamental interfaces that can
represent any structured document, as well as defining extended interfaces for representing an XML
document.
These extended XML interfaces need not be implemented by a DOM implementation that
only provides access to HTML documents; all of the fundamental interfaces in the Core section must
be implemented.
A compliant DOM implementation that implements the extended XML interfaces is required
to also implement the fundamental Core interfaces, but not the HTML interfaces.
The HTML Level 1 section provides additional, higher-level interfaces that are used with the
fundamental interfaces defined in the Core Level 1 section to provide a more convenient view of an
HTML document.
A compliant implementation of the HTML DOM implements all of the fundamental Core
interfaces as well as the HTML interfaces.
DOM Level 2 Specifications
DOM Level 1 was designed for HTML 4.0 and XML 1.0. With DOM Level 2, authors can
take further advantage of the extensibility of XML.
Simply put, anywhere you use XML, you can now use the DOM to manipulate it. The
standard DOM interface makes it possible to write software (similar to plug-ins) for processing
customized tag-sets in a language- and platform-independent way.
A standard API makes it easier to develop modules that can be re-used in different
applications. DOM Level 2 provides support for XML namespaces, extending and improving the
XML platform.
As more sites move to XML for content delivery, DOM Level 2 emerges as a critical tool for
developing dynamic Web content.
The DOM defines a standard API that allows authors to write programs that work without
changes across tools and browsers from different vendors.
But beyond this, it provides a uniform way to produce programs that work across a variety of
different devices, so all may benefit from dynamically generated content.
The DOM Level 2 Cascading Style Sheet (CSS) API makes it possible for a script author to
access and manipulate style information associated with contents, while preserving accessibility.
In web development, Cascading Style Sheets (CSS) is a stylesheet language used to describe
the presentation of a document written in a markup language.
Its most common application is to style web pages written in HTML and XHTML, but the
language can be applied to any kind of XML document, including SVG and XUL.
CSS is used by both the authors and readers of web pages to define colors, fonts, layout, and
other aspects of document presentation.
It is designed primarily to enable the separation of document content (written in HTML or a
similar markup language) from document presentation (written in CSS).
This separation can improve content accessibility, provide more flexibility and control in the
specification of presentational characteristics, and reduce complexity and repetition in the structural
content.
CSS can also allow the same markup page to be presented in different styles for different
rendering methods, such as on-screen, in print, by voice (when read out by a speech-based browser
or screen reader) and on Braille-based, tactile devices. CSS specifies a priority scheme to determine
which style rules apply if more than one rule matches against a particular element.
In this so-called cascade, priorities or weights are calculated and assigned to rules, so that the
results are predictable.
The Document Object Model Events Level 3, a platform- and language-neutral interface that
allows programs and scripts to dynamically access and update the content, structure and style of
documents.
The goal of the DOM Level 3 Events specification is to expand upon the functionality
specified in the DOM Level 2 Event Specification.
The specification does this by adding new interfaces which are complimentary to the
interfaces defined in the DOM Level 2 Event Specification as well as adding new event sets to those
already defined.
This specification requires the previously designed interfaces in order to be functional. It is
not designed to be standalone.
These interfaces are not designed to supercede the interfaces already provided but instead to
add to the functionality contained within them.
DOM Tree
DOM defines a logical tree-structure for an XML document. The basic building block of the
tree-structure is a node.
Nodes are generic containers that hold information about the elements, attributes, content,
comments and processing instructions that are stored in an XML document. An XML document can
be viewed as a single node that contains all the other nodes.
Consider the following code snippet:
<html>
<head>
<title>This is Shankar</title>
</head>
<body bgcolot=red>
<h1>Shankar</h1>
<p>DOM Tree</p>
</body>
</html>
There are two basic ways of assigning an event handler. The first, most used, and certainly obtrusive
technique is embedding it directly into the HTML markup, while the second is just including the
event handler within the own piece of JavaScript code. Definitely, this last one is the recommended
approach, since it allows us to maintain the HTML and the JavaScript pieces residing in different
layers, making the code much more flexible and portable.
Let’s illustrate the first approach, inserting the event handler inside its own HTML tag, appending it
as a regular attribute:
In the above example, we’ve embedded the event handler along with the JavaScript code to be
executed. As we can see, the HTML markup is rather dirty using the inline approach. Now, let’s
implement the same functionality, this time by inserting the event handler within the JavaScript
code. Like this:
<script language="javascript">
openLink=function(){
var devlink=document.getElementById('devlink');
devlink.onclick=function(){
window.open('http://www.devarticles.com');
return false;
window.onload=openLink;
</script>
An explanation is in order here. In this second example, we’ve built a completely separate script,
inserted the "onclick" event handler within the "openLink()" function, and then executed the script
when the page is loaded (utilizing "onload", another event handler). Note how we have dynamically
attached a new function to the link, without the need of declaring the function name. Undoubtedly,
this last technique is much better and cleaner than the first one.
Now we’ve grasped the general concept for assigning event handlers. Having explained the two
conventional ways to assign event handlers, let’s go one step further and learn a little more about the
manner the DOM handles events.
Understanding the DOM event flow: Event Capture and Event Bubble
Detecting events and assigning the proper event handlers with the DOM is really a
straightforward process, introducing a new manner for doing this.
What’s more, the two conventional approaches previously described are perfectly supported
and valid.
For a complete understanding of assigning event handlers with the DOM, it’s really necessary
first to explain the way that events are handled within its context.
Let’s assume we’re representing an extremely common situation, where the user passes the
mouse over a regular link present in a Web document. From a user’s point of view, the process
consists of just hovering on the link and that’s all.
Period. On the other hand, for the DOM, things are more complex and technical, generating a set
of processes that involves two phases, called Event Capturing and Event Bubbling respectively.
According to the previous example, when a user is passing the mouse over the link, these are the
events that take place, in the following order:
• The user moves the mouse over any tag containing the target <a> element.
• The user moves the mouse over the specific target <a> element.
The two processes prior to reaching the target <a> element are defined as taking place at the
event capturing phase. Once the event has reached the target, it travels back in the following way:
• The user moves the mouse over any tag containing the target <a> element.
As we can see, the complete process, including the two phases, is quite lengthy, and considerably
different from a user’s point of view. In order to clarify this explanation, here are a couple of
diagrams that show the entire event, as interpreted by theDOM:
The above images illustrate the event capturing and the event bubble phases, according to the
model implemented by the W3CDOM. As we’ll see shortly, there are significant differences
between the way that today’s browsers support event bubbling and event capturing.
Indeed, inline event handlers have been in use for a long time. As applications became more
complex, a clear need developed to implement HTML and JavaScript code in different layers.
Although basic, it’s quite useful to demonstrate how event phases are handled with inline
event handlers. Here’s is a sample of this:
</div>
In the previous example, we’ve attached the "onclick" event handler to the <div> element,
instead of assigning it directly to the link.
However, if we’re using a browser that supports event bubble, by just clicking on the <a>
element, the event will traverse the paragraph, reaching the <div> element and firing up the "alert"
box.
However, since messing up HTML with JavaScript is not recommended, the sample might be
rewritten as follows:
<script language="javascript">
var div=document.getElementById('testdiv');
div.onclick=function(){
</script>
And the HTML would be reduced to this:
<div id="testdiv">
</div>
For both cases, the result is the same, but the last one is definitely the way to go, since we removed
the inline event handler from the HTML.
At this point, we’ve playing around with some core definitions, explaining different
techniques for assigning event handling that have been in use for a long time, hopefully as a
reminder for choosing the right method when we’re dealing with event handlers nowadays.
In the browser arena, not so surprisingly, Nestcape and Microsoft came up with different
conclusions for event handling. Netscape’s approach was originally based in the capture phase,
establishing that any event should be handled when the event was traversing the Web document,
going through all of the containing elements, until reaching the target.
On the other hand, Microsoft branched to the event bubble direction, specifying that events
should take precedence at the bubble phase.
As we can see, the two models are radically opposed. Netscape 4 only supports event
capturing, while Internet Explorer only supports event bubbling. Mozilla, Opera 7 and Konqueror
support both approaches.
Older versions of Opera and iCab support neither. We’ll see more event handling browser
implementations in more detail shortly. As an introductory process, it’s more than enough.
Let's first review (for most of us, at least) the 2 common and conventional ways of setting up
an event handler- via HTML, or scripting. In both cases, a function or code is attached at the end,
which is executed when the handler detects the specified event.
We can define an event handler directly inside the relevant HTML tag, by embedding it as a
attribute. A piece of JavaScript is also included to tell the browser to perform something when the
event occurs. For example,
<a href="http://freewarejava.com" onMouseover="window.status='Click here for Java applets';return
true" onMouseout="window.status=''">Freewarejava.com</a>
Demo:
Here the event handler (onMouseover) is directly added inside the desired element (A), along with
the JavaScript to execute.
2) Via scripting
You can also assign and set up event handlers to elements using scripting, and inside your
script . This allows for the event handlers to be dynamically set up, without having to mess around
with the HTML codes on the page.
When setting up event handlers for an element directly inside your script, the code to execute
for the events must be defined inside a function.
Just look at the below, which does the same thing as above, but with the event handler
defined using scripting:
<script type="text/javascript">
function changestatus(){
window.status="Click here for Java applets"
return true
}
function changebackstatus(){
window.status=''
}
document.getElementById("test").onmouseover=changestatus
document.getElementById("test").onmouseout=changebackstatus
</script>
Event Handlers:
onclick: Use this to invoke JavaScript upon clicking (a link, or form boxes)
onload: Use this to invoke JavaScript after the page or an image has finished loading.
onmouseover: Use this to invoke JavaScript if the mouse passes by some link
onmouseout: Use this to invoke JavaScript if the mouse goes pass some link
onunload: Use this to invoke JavaScript right after someone leaves this page.
This is used check the browser compatibility mode and display the web page based on the
compatibility.
If there is no possibility to display the web page in specified format then the page itself shows error
message indicating that the browser you are using is not supported by the current page use specified
browser to display the web page.
Example:
if we try to open this website in FireFox(FF) then you will get error message.
Our Application detected that you are using browser other than IE6 and above. This website has
been designed to best fit with Internet explorer 6.0 and above.
A famous example of this specification allowance (taken to a perverse extreme) is the case of host
objects in Internet Explorer that are implemented as ActiveX objects. Simply evaluating their
methods (as well as some properties) will cause an exception to be thrown.
var el = document.createElement('div');
var parent = el.offsetParent; // IE throws an exception here
window.alert('Found it!');
} else {
window.alert('No such object or method');
}
Java Script Browser Detection
<div id="example"></div>
<script type="text/javascript">
document.getElementById("example").innerHTML=txt;
</script>
Server-Side Programming
Servlet Architecture
The life cycle of a servlet is controlled by the container in which the servlet has been deployed.
When a request is mapped to a servlet, the container performs the following steps.
• init()
• service()
• destroy()
init()
This method is called once for a servlet instance. When first time servlet is called, servlet container
creates instance of that servlet and loaded into the memory. Future requests will be served by the
same instance without creating the new instance. Servlet by default multithreaded application.init()
method is used for inilializing servlet variables which are required to be passed from the deployment
descriptor web.xml. ServletConfig is passed as the parameter to init() method which stores all the
values configured in the web.xml. It is more convenient way to initialize the servlet.
service()
This method is called for the each request. This is the entry point for the every servlet request and
here we have to write our businesslogic or any other processes. This method takes
HttpServletRequest and HttpServletresponse as the parameters. It is not mandatory to write this
method, normally developers are interested in writing doGet() or doPost() methods which is by
default called from the service() method. If you override service(), it is your reponsibility to call the
appropriate methods. If you are not overridden the service() method, based on the types of the
request the methods will be called.
destroy()
This method will be called once for a instance. It is used for releasing any resources used by the
servlet instance. Most of the times it could be database connections, Fill IO operations, etc. destroy()
is called by the container when it is removing the instance from the servlet container. Servlet
instance is deleted or garbage collected by the container only when the web server issues shut down
or the instance is not used for a long time.
Hello ClientServlet.java
1: import java.io.*;
2: import javax.servlet.*;
3: import javax.servlet.http.*;
4:
5: public class HelloClientServlet extends HttpServlet
6: {
7: protected void doGet(HttpServletRequest req,
8: HttpServletResponse res)
9: throws ServletException, IOException
10: {
11: res.setContentType("text/html");
12: PrintWriter out = res.getWriter();
13: out.println("<HTML><HEAD><TITLE>Hello Client!</TITLE>"+
14: "</HEAD><BODY>Hello Client!</BODY></HTML>");
15: out.close();
16: }
17:
18: public String getServletInfo()
19: {
20: return "HelloClientServlet 1.0 by Stefan Zeiger";
21: }
22: }
Lines 1 to 3 import some packages which contain many classes which are used by the Servlet
(almost every Servlet needs classes from these packages).
1: import java.io.*;
2: import javax.servlet.*;
3: import javax.servlet.http.*;
The Servlet class is declared in line 5. Our Servlet extends javax.servlet.http.HttpServlet, the
standard base class for HTTP Servlets.
In line 11 we use a method of the HttpServletResponse object to set the content type of the
response that we are going to send. All response headers must be set before a PrintWriter or
ServletOutputStream is requested to write body data to the response.
11: res.setContentType("text/html");
In lines 13 and 14 we use the PrintWriter to write the text of type text/html (as specified through
the content type).
The PrintWriter gets closed in line 15 when we are finished writing to it.
15: out.close();
This line is included for completeness. It is not strictly necessary. The Web Server closes the
PrintWriter or ServletOutputStream automatically when a service call returns. An explicit call to
close() is useful when you want to do some post-processing after the response to the client has
been fully written. Calling close() tells the Web Server that the response is finished and the
connection to the client may be closed as well.
Advantages of Servlets
Efficiency
More efficient –uses lightweight java threads as opposed to individual processes
Persistency
Servlets remain in memory
Servlets can maintain state between requests
Portability
Since servlets are written in Java, they are platform independent
Robustness
Error handling, Garbage collector to prevent problems with memory leaks
Large class library –network, file, database, distributed object components, security, etc.
Extensibility
Creating new subclasses that suite your needs
Inheritance, polymorphism, etc.
Security
Security provided by the server as well as the Java Security Manager
Eliminates problems associated with executing cgi scripts using operating system “shells”
Powerful
Servlets can directly talk to web server
Facilitates database connection pooling, session tracking etc.
Convenient
Parsing and decoding HTML form data, reading and setting HTTP headers, handling cookies,
etc.
Methods in HttpServlet
i. doGet
• Performs the HTTP GET operation; the default implementation reports an HTTP
BAD_REQUEST error. Overriding this method to support the GET operation also
automatically supports the HEAD operation. (HEAD is a GET that returns no body in the
response; it just returns the request HEADer fields.)
• Servlet writers who override this method should read any data from the request, set entity
headers in the response, access the writer or output stream, and, finally, write any response
data. The headers that are set should include content type, and encoding. If a writer is to be
used to write response data, the content type must be set before the writer is accessed. In
general, the servlet implementor must write the headers before the response data because the
headers can be flushed at any time after the data starts to be written.
• Setting content length allows the servlet to take advantage of HTTP "connection keep alive".
If content length can not be set in advance, the performance penalties associated with not
using keep alives will sometimes be avoided if the response entity fits in an internal buffer.
• Entity data written for a HEAD request is ignored. Servlet writers can, as a simple
performance optimization, omit writing response data for HEAD methods. If no response data
is to be written, then the content length field must be set explicitly.
• The GET operation is expected to be safe: without any side effects for which users might be
held responsible. For example, most form queries have no side effects. Requests intended to
change stored data should use some other HTTP method. (There have been cases of
significant security breaches reported because web-based applications used GET
inappropriately.)
• The GET operation is also expected to be idempotent: it can safely be repeated. This is not
quite the same as being safe, but in some common examples the requirements have the same
result. For example, repeating queries is both safe and idempotent (unless payment is
required!), but buying something or modifying data is neither safe nor idempotent.
Parameters:
• req - HttpServletRequest that encapsulates the request to the servlet
• resp - HttpServletResponse that encapsulates the response from the servlet
Throws: IOException
• if detected when handling the request
Throws: ServletException
• if the request could not be handled
ii. doPost
Parameters:
• req - HttpServletRequest that encapsulates the request to the servlet
• resp - HttpServletResponse that encapsulates the response from the servlet
Throws: IOException
• if detected when handling the request
Throws: ServletException
• if the request could not be handled
iii. doPut
Parameters:
• req - HttpServletRequest that encapsulates the request to the servlet
• resp - HttpServletResponse that encapsulates the response from the servlet
Throws: IOException
• if detected when handling the request
Throws: ServletException
• if the request could not be handled
iv. doTrace
v. doDelete
Parameters:
• req - HttpServletRequest that encapsulates the request to the servlet
• resp - HttpServletResponse that encapsulates the response from the servlet
Throws: IOException
• if detected when handling the request
Throws: ServletException
• if the request could not be handled
Sessions
The basic premise of sessions is that only a session ID is stored on the client. On the server, that
ID is associated with other "real world" information such as a user name, shopping cart etc.
(This is a difference compared to using "raw" cookies to store information such as a user name
on the client.) HTTP sessions typically operate is as follows:
• when a client first requests a page where we need to start a session (e.g. the "login" page), our
server allocates a random session ID;
• that session ID is then communicated back to the client;
• whenever the client subsequently requests a page from our server (or relevant path from our
server), it sends back the same session ID;
• on the server, we can associate information with that session ID;
• on the server, we can eventually decide that the session has "expired", and/or provide the user
with a means to manually tell our server to "expire" the session.
• HTTP is the stateless protocol: it provides no way for the server to recognize that a sequence
of requests are all from the same client.
• Privacy advocates may consider this the feature, but it causes problems because many web
applications aren't stateless.
Session Tracking
To support the software that needs keep track of the state, Java Servlet technology provides an API
for managing sessions and allows several mechanisms for implementing sessions.
Session tracking is a great thing. Every user can be associated with a javax.servlet.http.HttpSession
object that servlets can use to store or retrieve information about that user.
Any set of arbitry can be saved by the Java objects in a session object.
For example, a user s session object provides a convenient location for a servlet to store the user s
shopping cart contents.
3.Http Session
1.URL Rewritting
You can append some extra data on the end of the each URL that identifies the session, and the
server can associate that session identifier with data it has stored about that session only. This is also
an excellent solution, and even has advantage that it works with the browsers that don't support
cookies or where the user has disabled cookies. However, it has most of same problems as cookies,
namely that the server-side program has a lot of straightforward but tedious processing to do. In
addition, you have to be very careful that every URL returned to user (even via indirect means like
Location fields in server redirects) has the extra information appended. And, if the user leaves
session and comes back via a bookmark or link, the session information can be lost.
3.Http Session
The HttpSession interface is implemented by the services to provide an association between an
HTTP client and HTTP server. This association, or session, persists over multiple connection and/or
requests during a given time period. Sessions are used to maintain the state and user identity across
multiple page requests.
A session can be maintained either by using the cookies or by URL rewriting. To expose whether the
client supports cookies, HttpSession defines the isCookieSupportDetermined method and an
isUsingCookies method.
HttpSession defines the methods which store these types of data:
• Standard session properties, such as an identifier for the session, and the context for the
session.
• Application layer data, accessed using this interface and stored using the dictionary-like
interface.
4.Secure Socket Layer(SSL)
The Secure Sockets Layer protocol, or SSL, sits between application-level protocol (in this case
HTTP) and the low-level transport protocol (for the Internet, almost exclusively TCP/IP). It handles
the details of the security management using public key cryptography to encrypt all client/server
communication. SSL was introduced by Netscape with Netscape Navigator 1. It has since become
the de facto standard for the secure online communications and forms the basis of he Transport
Layer Security (TLS) protocol currently under development by the Internet Engineering Task Force.
SSL Version 2.0, the version first to gain the widespread acceptance, includes support for server
certificates only. It provides the authentication of the server, confidentiality, and integrity. Here's
how it works:
• A user connects to the secure site using the HTTPS (HTTP plus SSL) protocol. (You can
detect sites using the HTTPS protocol because their URLs begin with https: instead of http:.)
• The server signs its public key with its private key and sends it back to browser.
• The browser uses server's public key to verify that the same person who signed the key
actually owns it.
• The browser check to see whether a trusted certificate authority signed the key. If one didn't,
the browser asks the user if the key can be trusted and proceeds as directed.
• The client generates a symmetric ( DES) key for session, which is encrypted with the server's
public key and sent back to the server. This new key is used to encrypt all the subsequent
transactions. The symmetric key is used because of high computational cost of public key
cryptosystems.
Cookies
Cookies are small bits of textual information that the Web server sends to the browser and that the
browser returns unchanged when visiting the same Web site or domain later
You can use HTTP cookies to store information about a shopping session, and each subsequent
connection can look up the current session and then extract information about that session from
some location on the server machine. This is an excellent alternative, and is the most widely used
approach. However, even though servlets have a high-level and easy-to-use interface to cookies,
there are still a number of relatively tedious details that need to be handled:
• Extracting the cookie that stores the session identifier from the other cookies (there may be
many, after all),
• Setting an appropriate expiration time for the cookie (sessions interrupted by 24 hours
probably should be reset), and
• Associating information on the server with the session identifier (there may be far too much
information to actually store it in the cookie, plus sensitive data like credit card numbers
should never go in cookies).
• Identifying the user during an e-commerce session. Many on-line stores use the "shopping
cart" metaphor in which the user selects an item, adds it to his shopping cart, then continues
shopping. Since HTTP connection is closed after each page is sent, when the user select a
new item for his cart, how does the store know that he is the same user that put the previous
item in his cart? Cookies are the good way of accomplishing this. In fact, this is so useful that
servlet have an API specifically for this, and servlet authors don't need to manipulate cookies
directly to make use of it.
• Avoiding username and password. Many large sites require you to register in order to use
their service, but it is inconvenient to remember the username and password. Cookies are the
good alternative for low-security sites. When a user registers, a cookie is sent with a unique
user ID. When the client reconnects at the later date, the user ID is returned, the server looks
it up, determines it belongs to the registered user, and doesn't require an explicit username
and password.
• Customizing a site. Many "portal" sites let you customize the look of main page. They use
cookies to remember what you wanted, so that you get that result initially for the next time.
I'll give an example like this later in this section of the tutorial.
• Focusing advertising. The search engine charge their customers much more for displaying
"directed" ads than "random" ads. That is, if you do a search on "Java Servlets", a search site
can charge much more for an ad for the servlets development environment than an ad for an
on-line travel agent. On the other hand, if the search had been "Bali Hotels", the situation
would be the reversed. The problem is that they have to show a random ad when you first
arrive and haven't yet performed the search, as well as when you search on something that
doesn't match any ad categories. Cookies let them remember "Oh, that's the person who was
searching for such and such previously" and displays an appropriate (read "high priced") ad
instead of a random (read "cheap") one.
Creating Cookies
A Cookie is created by calling Cookie constructor, which takes two string: the cookie name and the
cookie value
The following example describes how to create a cookie
Cookie userCookie = new Cookie("user", "uid1234"); response.addCookie(userCookie);
URLRewriting
It is used to maintain the session. Whenever the browser sends a request then it is always
interpreted as a new request because http protocol is a stateless protocol as it is not persistent.
Whenever we want that out request object to stay alive till we decide to end the request object
then, there we use the concept of session tracking.
In session tracking firstly a session object is created when the first request goes to the server.
Then server creates a token which will be used to maintain the session.
The token is transmitted to the client by the response object and gets stored on the client
machine. By default the server creates a cookie and the cookie get stored on the client machine.