In order for the server-side application to receive user input and actions, and present the results of these back to the user, it needs to provide a client-side user interface. Because all web applications are accessed via a web browser, these interfaces all share a common core of technologies. However, these have been built upon in various diverse ways, and the ways in which applications leverage client-side technology has continued to evolve rapidly in recent years.
The core technology used to build web interfaces is the hypertext markup language (HTML). This is a tag-based language that is used to describe the structure of documents that are rendered within the browser. From its simple beginnings as a means of providing basic formatting to text documents, HTML has developed into a rich and powerful language that can be used to create highly complex and functional user interfaces.
A large amount of communication from client to server is driven by the user clicking on hyperlinks. In web applications, hyperlinks frequently contain preset request parameters. These are items of data which are never entered by the user but which are submitted because the server placed them into the target URL of the hyperlink on which the user clicks. For example, a web application might present a series of links to news stories, each having the following form:
<a href=”/news/showStory?newsid=19371130&lang=en”>Sale now on!</a>
When a user clicks on this link, the browser makes the following request:
GET /news/showStory?newsid=19371130&lang=en HTTP/1.1
The server receives the two parameters in the query string ( newsid and lang ) and uses their values to determine what content should be presented to the user.
While hyperlink-based navigation is responsible for the majority of client-to-server communications, in most web applications there is a need for more flexible ways of gathering input and receiving actions from users. HTML forms are the usual mechanism for allowing users to enter arbitrary input via their browser. A typical form is as follows:
<form action=”/secure/login.php?app=quotations” method=”post”>
username: <input type=”text” name=”username”><br>
password: <input type=”password” name=”password”>
<input type=”hidden” name=”redir” value=”/secure/home.php”>
<input type=”submit” name=”submit” value=”log in”>
When the user enters values into the form and clicks the submit button, the browser makes a request like the following:
POST /secure/login.php?app=quotations HTTP/1.1
In this request, there are several points of interest reflecting how different aspects of the request are used to control server-side processing:
■ Because the HTML form tag contained an attribute specifying the POST method, the browser uses this method to submit the form, and places the data from the form into the body of the request message.
■ In addition to the two items of data entered by the user, the form contains a hidden parameter ( redir ) and a submit parameter ( submit ). Both of these are submitted in the request and may be used by the server-side application to control its logic.
■ The target URL for the form submission contains a preset parameter ( app ), as in the hyperlink example shown previously. This parameter may be used to control the server-side processing.
■ The request contains a cookie parameter ( SESS ), which was issued to the browser in an earlier response from the server. This parameter may be used to control the server-side processing.
The previous request contains a header specifying that the type of content in the message body is x-www-form-urlencoded . This means that parameters are represented in the message body as name/value pairs in the same way as they are in the URL query string. The other content type you are likely to encounter when form data is submitted is multipart/form-data . An application can request that browsers use multipart encoding by specifying this in an enctype attribute in the form tag. With this form of encoding, the Content-Type header in the request will also specify a random string that is used as a separator for the parameters contained in the request body. For example, if the form specified multipart encoding, the resulting request would look like the following:
POST /secure/login.php?app=quotations HTTP/1.1
Content-Type: multipart/form-data; boundary=————7d71385d0a1a
Content-Disposition: form-data; name=”username”
Content-Disposition: form-data; name=”password”
Content-Disposition: form-data; name=”redir”
Content-Disposition: form-data; name=”submit”
Hyperlinks and forms can be used to create a rich user interface capable of easily gathering most kinds of input which web applications require. However, most applications employ a more distributed model, in which the client side is used not simply to submit user data and actions but also to perform actual processing of data. This is done for two primary reasons:
■ It can improve the application’s performance, because certain tasks can be carried out entirely on the client component, without needing to make a round trip of request and response to the server.
■ It can enhance usability, because parts of the user interface can be dynamically updated in response to user actions, without needing to load an entirely new HTML page delivered by the server.
■ Validating user-entered data before this is submitted to the server, to avoid unnecessary requests if the data contains errors.
■ Dynamically modifying the user interface in response to user actions; for example, to implement drop-down menus and other controls familiar from non-web interfaces.
■ Querying and updating the document object model (DOM) within the browser to control the browser’s behavior.
Thick Client Components
■ Java applets
■ ActiveX controls
■ Shockwave Flash objects
NEXT is ..State and Sessions…….,