Building Web Applications with UML: Web Application Basics

This chapter is from the book

Building Web Applications with UML, 2nd Edition

Learn More Buy

This chapter is from the book

This chapter is from the book 

Building Web Applications with UML, 2nd Edition

Learn More Buy

HTML

Browsers, in addition to establishing the network connections and protocols for document interchanges, need to render the document on a display. TCP/IP and HTTP don't address this at all. The rendering of content is managed by the browser. This is where the Hypertext Markup Language (HTML) fits in. HTML, used to express the content and the visual formatting of a Web page, is a tag language based on the Standard Generalized Markup Language (SGML), which is a much broader language used to define markup languages for particular purposes. HTML is simply one specific application of SGML, suited to the presentation of textual documents. HTML contains tags that define how text is to be formatted—font, size, color, and so on—on the display. Tags are used to point to images to include in the display, as well as to define links to other Web pages. Like HTTP, HTML is an evolving standard managed by the World Wide Web Consortium standards body. The current W3C recommendation is HTML 4.01, which is based on the earlier HTML 3.2 and HTML 2.0 specifications.

One important thing to note is that HTML is a language that specifies how documents should be displayed on a computer screen. This raises several problems when the Web system needs to enable users to print formatted documents. Many documents, especially forms, have strict printing requirements. If a Web application needs to allow users to print forms or documents in which the typesetting is important—page breaks, font sizes, margins, and so on—additional elements will have to be added to the system. HTML does not address printing in detail. Several attempts to make HTML more suitable for printing have been made, but so far with little more than page break support, so Web applications that need strict printing capabilities must include additional components in their architecture.

HTML defines a set of tags that can be used either to tell the browser how to render something or to define a link to another Web page. All tags are enclosed by angle brackets (< and >). Tags are usually used in pairs, with a beginning and an ending tag. For example, to make a word italicized, the emphasis tag—<em>—is used. A sample sentence and the HTML to render it follow:

This is really neat.
This is really <em>neat</em>.

Some tags accept parameters, which are placed inside the brackets and are usually a parameter name, followed by an equal sign and then the value enclosed by double quotation marks. The following HTML for a hyperlink to another Web document uses the anchor tag, <a>:

The HTML 4 spec can be found at the <a href="http://www.w3c.org">W3C Web site</a>.

Most browsers render the hyperlink with an underscore:⁴

The HTML 4 spec can be found at the W3C Web site.

The anchor tag uses the parameter href to define the location and the type of the link.

HTML pages are usually text files on the Web server's file system. The language was originally intended to be easy to learn, so that people interested in publishing content could easily specify how the content should be rendered. The key points here are "easy to learn" and "any display terminal." Because a Web system is, potentially, made up of many types of computers, a device-independent way was needed to specify basic formatting commands. For example, specifying a font by name would be a problem if the browser's computer didn't recognize the font name or didn't have the ability to render that font.

This was not a problem for early Web page writers, who were more interested in content than presentation. The language was simple enough to express only the basic formatting capabilities expected for the scientific community. The first generation of Web pages were all written manually, without the aid of WYSIWYG editors.

When the Internet and the Web became commercial, this simple language and its limitations did become a problem. Exact formatting of pages is very important to companies, especially e-commerce companies on the Internet. As in print advertisement, the look of a Web page is very important to potential customers and clients. HTML evolved to meet these needs, enabling more precise formatting of content by introducing new tags and parameters to the language.

What didn't change, though, was that the document content and the presentation information are coupled. The content of an HTML-formatted Web page is a mix of document content—the text or pictures that are displayed by the browser—and rendering instructions, such as bold, indent, font size, and so on. Figure 2-2 shows how HTML renders in a browser.

FIGURE 2-2 (a) HTML content (b) rendered in a browser

All the formatting commands are embedded with the content of the document. It is possible to separate some of the formatting specifics from the content with style sheets; even with their use, however, complete separation is not possible. A related term and technology—content management, discussed in Chapter 7, Defining the Architecture—provides more concrete examples of how the separation of content from formatting is an ongoing and important topic to Web application developers.

Style sheet specifications allow Web page authors to define a separate layout, such as color, font, and margins, template that could be used by many other content documents. This helps maintain a consistent look-and-feel across a Web site.

It should be noted that some browsers, especially older and nontraditional browsers, such as PDAs (personal digital assistants) and mobile phones, do not support the use of style sheets. Even so, the W3C recommends the use of style sheets, and is continuing to refine HTML so that in the future, there will be an even further separation of content and presentation. The emergence of XML (Extensible Markup Language), discussed in Chapter 4, Beyond HTTP and HTML, plays a key role in this separation.

One mechanism for separating the content of an HTML page from its presentation is server-side includes (SSI). The NCSA (National Center for Supercomputing Applications) has defined a simple tag that can be used to include HTML fragments that need to be shared across a number of response pages. Typically, these are standard prologs, epilogs, or legal disclaimers and copyright notices. By spreading the content on several shared pages, it is possible to manage a single point of update.⁵ The tag simply specifies the name of a file in the Web site's file system:

<!--#include file="banner.html"-->

HTML has special tags that allow the Web page author to use multimedia information such as images, sound, and video, in addition to textual information. Instead of embedding the multimedia data in the page with the text, the tags specify separate URLs for each item. This means that the browser will make an additional request and connection to the server for each image or multimedia item mentioned in the original Web page. To the Web application architect and designer, this means that certain exceptions need to be taken into account when designing the application. These situations usually are invalid URLs or missing files. It also implies that Web applications with lots of images and multimedia types may cause significant network performance penalties when establishing so many discrete connections. Remember, the choice of a connectionless protocol benefits the robustness of the system, not its performance.

A full discussion of HTML and its tags will not be presented here; the topic is beyond the scope of this book and has been done very well in countless other books. What does need to be discussed here is the architecturally significant elements of the language, especially as they relate to Web applications. Like separating content from presentation, the architecturally significant elements of a Web page need to be brought out and modeled as such. For example, a design model of a Web application is not very interested in the font size or color of the text used in a display, but it is very interested in the sets of Web pages that can be navigated to. The following sections discuss these important elements of HTML.

Anchors

A hyperlink to a Web page is created with the HTML anchor tag: <a>. The tag uses several parameters, the most important of which is href. This tag can be used without an href value, but in this case, the tag is being used as an internal bookmark of the page and as such is not architecturally significant to the design model but could be significant in the user experience model (see Chapter 9). The href parameter, which specifies the linked document's URL, may contain a relative URL, which doesn't specify the full URL, including the host's name, but rather expects the browser to use as the host the host that supplied the page containing the hyperlink. For example, the following anchor tag is perfectly acceptable:

We have a full line of <a href="prod.html">products</a> to choose from.

In this example, the link is to a page on the same machine and in the same directory as the current page.

In addition to the location and the name of the Web page, an anchor can pass along parameters with the page request. When parameters are specified in a page request, it usually means that the requested page is executable. The requested Web page is capable of accessing the parameter information and using it to build the returned page. Parameters are passed with the request as name/value pairs separated by the ampersand symbol (&). The parameters are separated from the Web page by a question mark (?). The following page request passes along two parameters: ProductID and RateCode. The ProductID is assigned the value 452, and the RateCode is given a value of B.

http://www.mystore.com/catalog/products.jsp?ProductID=452&RateCode=B

The requested page is products.jsp. The extension of the Web page gives a clue that the enabling technology used by the executable page is JavaServer Pages.

In addition to href, the other significant parameter is target. When a hyperlink is selected, it typically loads the new document in the same browser window as the original document. This is not always the case. When frames are used to divide up a browser's display area, each frame displays a separate Web page. Frames are discussed in detail later.

When frames or multiple browsers are used, it is possible for a hyperlink to specify a frame or browser instance to load in. Frames and browser instances can be assigned any name, although a few target names are reserved.

In the following example, the anchor tag specifies a named target: maindoc.

<a href="chap1.html" target="maindoc" > Chapter 1, Web Application Basics. </a>

Forms

HTML form elements distinguish a Web site from a Web application. The HTML form part of a Web page can accept user input. An HTML form is a collection of fields that allow users to enter text or to select from a list. In addition to text boxes, form fields can be rendered by buttons, check boxes, and radio buttons. If a Web page has a form in it, the browser will render that form with the appropriate user interface controls and allow the user to enter and to change its values. Most forms have a special button in them that, when clicked by the user, submits the form and its contents to the Web server as part of another Web page request. The Web server receives a request for a special Web page, or executable module, that is capable of reading the form's field values and processing them on the server. The ultimate result is a new HTML page that is sent back to the requesting browser; see Figure 2-3.

More detailed discussions of form-processing enabling technologies are given later in this book. The general concept, however, is that the executable page is used by the Web server to process the form's values and to produce a new HTML page to send back to the browser. Most often, the processing involves communicating with objects on the server or with databases. Forms are a key mechanism in the interaction of Web application users but by no means the only one. More sophisticated mechanisms for getting user input are discussed in Chapter 3, Dynamic Clients.

FIGURE 2-3 An executable Web page processing a form's data

A form is defined by the <form> tag. The two principal parameters are action and method. The action parameter is the URL of the executable Web page that processes the form. The method parameter specifies how the data will be sent to the server. The two valid values are GET and POST. When GET is used, the values of all the fields in the form are appended to the URL as parameters. The Web server sees the form submission as a typical GET request, as if it were from a standard anchor tag. The W3C does not recommend using GET, as it has some internationalization problems and will not work for large forms. Instead, the value POST is preferred. The POST method tells the browser to package up the field values in a special section of the request called the data body.

Plain-vanilla HTML has only a few core form elements: <input>, <select>, and <textarea>. The <select> tag specifies either a list box or a drop-down list from which the user can select something. The <textarea> tag is a multiline text input control and allows users to enter in large blocks of text. The <input> tag is really an overloaded tag that could be configured to act like a push button, a check box, a radio button, or a single-line text entry field.

The <input> tag's name parameter identifies the field's name. This name is used by the executable Web page when processing the form's data. The <input> tag's type parameter determines what type of user interface control should be used and what type of data to accept. The most common values are:

Other types exist, but these define the core set of input types that are used and available in most browser implementations. The key point here is that simple forms collect textual information from the user—either directly or by translating a check box, a button, or a list box selection into one—and define the mechanism by which it gets submitted to the server.

The following HTML fragment defines a simple form for collecting log-on information:

<form method="POST" action="cgi-bin/logon.pl">
<p>Username: 
<input type="text" name="username" size="10"></p>
<p>Password: 
<input type="password" name="password" size="10"></p>
<p>Logon as:</p>
<p>
<input type="radio" name="Role" value="Supervisor">Supervisor<br>
<input type="radio" name="Role" value="Clerk">Clerk<br>
<input type="radio" name="Role" value="Guest">Guest
</p>
<p><input type="submit" value="Logon" name="LogonBtn"></p>
</form>

The browser's rendering of the form is shown in Figure 2-4.

FIGURE 2-4 Rendered HTML form

Frames

A controversial element in the HTML arsenal is a frameset. A frameset divides up the browser's display area into rectangular regions, each rendering its own HTML document. The <frameset> tag defines the number of frames the display should be broken up into and their sizes or proportions. Separate <frame> tags identify each of the frames with a target name. The <frame> tags also tell the browser which Web pages to request for each frame when initializing the page. Once a frameset page is loaded, with all its individual frames loaded as well, the user can work with the page. The user can select a hyperlink in any of the displayed pages. The link might specify a new document for the frame that it is in or a page to be loaded in another named frame.

The most common use of frames is to define a table of contents and main document frame. The Web page in the table of contents frame is typically a long list of table of content entries, each a hyperlink to an area of the Web site. Each of the links specifies that the "main document" frame, or target, is where the linked Web page should be rendered. The output produced from the JavaDoc application is another excellent example of the use of frames.

The parameters cols and rows of the <frameset> tag define the initial size and the number of frames in the set. For example, the value "20%,50%,*" specifies three frames to be defined. The first occupies 20 percent of the screen; the second, 50 percent; the third, the remaining space, 30 percent. Instead of percentages, explicit widths can also be defined, and that's where the * value becomes useful. Of course, it is entirely possible for a frame to contain another frameset. This allows designers a little more freedom from a simple matrix frame design and can be used to produce any combination of rectangular regions in the browser's display.

The following HTML fragment defines a simple table of contents–like page. The table of contents appears in the leftmost frame and occupies 20 percent of the display.

<frameset cols="20%,80%">
  <frame name="toc" src="toc.html">
  <frame name="maindoc" src="intro.html">
</frameset>

Names are specified for each frame. A link in the table of contents frame would specify "maindoc" as the target for the link. For example, clicking on the following HTML link would display the Chapter 1 page in the main document frame. The table of contents frame would remain the same.

<a target="maindoc" href="chapter1.html">Chapter 1. Web Application Basics</a>

The frameset Web page itself typically doesn't contain content like other Web pages do. Most do contain enough content to tell the user that a frames-capable browser is needed to view the page and to provide a link to a page that doesn't require one. This is sometimes necessary on the Internet, as not all browsers support frames.

The controversy over frames centers on user interface preferences and complexity. Some people don't like frames. Frames do, however, raise the level of complexity a bit, as now multiple Web pages are interacting with the user at the same time. This is what makes frames an architecturally significant element.