Sams Teach Yourself Web Publishing with HTML and CSS in One Hour a Day (5th Edition) P70 potx

Web Applications
Server-side web programming in Java began with Java servlets, which were in some ways the server-
side analogue of Java applets. Servlets are also similar to CGI programs. The main difference between a
servlet and a CGI program is that servlets have to run in the context of an application that's known as a
servlet container. In this sense, they're more like ASP programs. Just as the IIS understands how to
interpret and execute ASPs, the servlet container understands how to pass requests on to servlets and
send the output back to the user. In some cases, the web server serves as the servlet container; in
others, the servlet container is a separate application that is connected to the web server.
In any case, you can write servlets and deploy them on your servlet container. Once you've written a
servlet and mapped it to a particular URL, it can respond to requests the same way a CGI program can.
What does this have to do with Java Server Pages? Java Server Pages (or JSPs) are just a simpler way
to create servlets. A JSP looks a lot like an ASPit's an HTML page that optionally contains scriptlets and
directives. In the JSP world, the scriptlets are written using Java. The trick here is that when a servlet
container serves up a JSP, it converts it into a servlet, compiles that servlet into a Java class file, and
then maps it to the path where the JSP is located. So, a JSP at
/index.jsp is turned into a servlet that is
called whenever that path is requested.
The syntax for JSPs is virtually identical to that of ASP files. Scriptlets are defined in exactly the same
way. In Java, it looks like this:
<%
String aString = "This is a string.";
response.write(aString);
%>

The expression evaluation feature in JSP is also exactly the same as it is in ASP. To print out the value
of
aString without bothering with response.write(), use the following:
<%= aString %>

There are some other constructs associated with JSP as well. These directives follow this pattern:
<%@page language="Java" %>

The fact that it starts with <%@ indicates that it's a directive. page is the name of the directive and
language is an attribute. This directive indicates that the language used in the scriptlets on the page is
Java. In truth, this is the only valid option; JSPs must use Java as their programming language. Perhaps
the most common attribute of the
page directive that you'll see is the import attribute, which is used to
indicate that a particular class is used on your page. If you're not a Java programmer, imports might be
a bit confusing for you. Just remember that you'll see a lot of them of you work on complex JSPs.
There's also an alternative form of directives for JSPs that use an XML-based notation. To see how they
differ from normal directives, let's look at how you include files in the JSP world. The first method uses a
normal-looking include:
<%@include file="footer.jsp" %>

This directive includes a file called footer.jsp from the current directory in place of the directive. When
you use the
include directive, the included file is inserted at compile time. What this means is that the
file:///G|/1/0672328860/ch19lev1sec1.html (5 von 7) [19.12.2006 13:50:09]
Web Applications
file is included before the JSP is converted to a servlet. For programmers, it means that code in the
included file can interact with code in the files that include it. For example, you could set the copyright
date in a variable in the including file, and reference that variable to print out the variable in the
included file.
You can also include files using JSP's XML-style directives. To include
footer.jsp using the XML directive,
the following code is used:
<jsp:include template="footer.jsp" />

When you use this type of include, it's treated as a runtime include. This differs from the previous in
that runtime includes are only included after the page has been converted into a servlet and run. The
include is processed or read in separately at that point, which means that variables can't be shared

between the included file and the including file.
The last common constructs you'll hear about in the JSP world are taglibs. To make things easier for
people who aren't Java programmers, the developers of the J2EE specification created a way to provide
custom tags (called taglibs, short for tag libraries) that you can use as part of your pages. Not only can
programmers create their own custom tags, but there are a number of projects working to create
standard custom tags that encapsulate common functionality needed by many web applications. The
taglib directive is used to make a tag library available for a JSP:
<%@ taglib uri="/WEB-INF/app.tld" prefix="app" %>

The uri attribute provides the URL for the descriptor file for the tag library. The prefix attribute
indicates how tags associated with the tag library are identified. For example, if there's a tag library tag
called
blockquote, it is differentiated from the standard <blockquote> tag by using the prefix, like this:
<app:blockquote>Some stuff.</app:blockquote>

Many programmers write their own tag libraries that provide functionality specific to their applications.
However, Sun has also defined a standard set of tag libraries to provide functionality common to many
applications. This group of libraries is called JSTL (Java Standard Tag Libraries). You can read more
about JSTL at
/>You can find an actual implementation of JSTL at
/>intro.html.
The JSTL tags provide functionality for things such as loops, conditional operations, and processing XML.
There's a lot more to building web applications using Java and J2EE than I've discussed here. I've just
provided an overview for you in case you need to apply your HTML skills to a web application written in
Java. Hopefully, when you run into one of these applications, you'll have seen enough here not to be
confused by the JSP syntax.
PHP
PHP is yet another language that enables you to embed scripts in your web pages. ASP is really part of
Microsoft's overall software development platform, and similarly, J2EE is part of the Java universe. PHP,
file:///G|/1/0672328860/ch19lev1sec1.html (6 von 7) [19.12.2006 13:50:09]

Web Applications
on the other hand, is completely independent. Rather than building on a general-purpose language, PHP
is a programming language unto itself. The language uses a C-like syntax that also has some things in
common with Perl. Like ASP and JSP, it can be interspersed with your HTML. Usually, you'll find that PHP
files have the extension
.php, but the web server can be configured to treat any files as PHP files. You
can even set things up so that files with the extension
.html are treated as PHP files.
There are two ways to include script code in your pages:
<?php
echo("Hello.");
?>

There's also a more concise notation for adding scripts to your page:
<?
echo("Hello.");
?>

This was the traditional notation for adding PHP code to web pages, but it conflicts with XML, so <?php ?
>
was added to differentiate between the two. If you're starting out, you should stick with the <?php ?>
notation because doing so could save you trouble later, and it's not that much more trouble.
One of the nicest things about PHP is that it's completely free, and can be easily installed to work with
Apache, the most popular web server. For this reason, many, many web hosting providers include
support for PHP with their hosting packages. It's fairly simple to install, and is neither large nor
unwieldy, so you can run it yourself with little trouble. PHP is also easier to learn than some of the other
systems because it's not just an extension of a larger programming environment. You can find out more
about PHP at
/>As I've done with the other technologies, let me explain how to include external files in your pages. In
the PHP world, there are four functions that can be used to include external files in PHP documents. All

of them are compile-time includes for the purposes of PHP. The functions are
include(), require(),
include_once(), and require_once().
Both
include() and require() accept the path to a file as an argument. The difference is that if you use
include() and the file cannot be read for some reason, a warning is printed but the page continues to be
processed. If you use
require(), a fatal error occurs if the included file cannot be read. include_once()
and
require_once() are exactly the same, except that if the file to be included has already been included
earlier on the page, the include will be ignored. This may seem strange if you're thinking about including
content, but it's helpful if you're including code. Let's say you have a file that sets up a bunch of
variables used later on your page. It probably makes sense to use
require_once() to make sure that
those variables aren't set more than once.


file:///G|/1/0672328860/ch19lev1sec1.html (7 von 7) [19.12.2006 13:50:09]
Server-Side Includes



Server-Side Includes
Now that I've described a number of popular web application platforms, let me describe something much
simpler that you may find more useful, at least in the immediate future. Most web servers support an
extension called server-side includes (SSI) that enable you to place directives in your pages that are
processed by the server when the pages are downloaded. All directives follow the same format. The
basic format is
<! #directive attribute=value attribute=value >

Note that SSI directives are cleverly disguised as HTML comments. The advantage is that if the server
doesn't process the directives, the browser will ignore them. This is particularly useful when you're
previewing pages that have SSI directives embedded in them locally.
Let's look at the directive in more detail. The directive name indicates how the directive should be used.
In the ASP section earlier in this lesson, you saw that the
include directive is used to include external
files in an HTML document. The directive is followed by one or more
attribute and value pairs. These
pairs define how the directive is used. For example, the
include directive has two possible attributes
(which are mutually exclusive):
file and virtual. The values associated with both of them are paths to
files to include. As mentioned previously, the
file attribute is used to load files from the current
directory or below it. The
virtual attribute indicates that the file can appear anywhere in the document
root.
Here are a couple of examples of
include directives:
<! #include file="includes/footer.html" >
<! #include virtual="/includes/footer.html" >

Any web server that claims to support server-side includes will support the include directive. Apache,
the torchbearer for SSI, supports many other directives as well.
Table 19.1 contains a list of all the directives supported by Apache. You can read more about them at
/>Table 19.1. SSI Directives Supported by Apache
Directive Usage
config
Enables you to configure the error message to be displayed if a directive fails, and the
format for displaying date and time information and file size information.

echo
Prints out the value of an include variable.
file:///G|/1/0672328860/ch19lev1sec2.html (1 von 4) [19.12.2006 13:50:10]
Server-Side Includes
exec
Executes a CGI program or command and includes the results in the page. (This directive
is usually disabled for security reasons.)
fsize
Prints out the size of the specified file. The virtual and file attributes are used with this
directive, just as they are with the
include directive.
flastmod
Prints the date the specified file was last modified. Supports the file and virtual
attributes.
include
Includes a file in the page.
printenv
Prints a list of all environment variables and their values.
set
Sets a variable to a value.

Using Server-Side Includes
Let's look at how you might use server-side includes on a real site. As I said before, includes are the
most common SSI directives used on most sites. Using includes, you can save a ton of work by bundling
up content that's common to more than one page into separate files that are included on each of those
pages. Let's look at an example that demonstrates how to use SSI on a real site. On many sites, you'll
find that navigational elements are shared among pages, and the header and footer are common to
every page.
First of all, let's take a look at the files common to every page, the header and footer. Here's the source
code to the header file:

<div id="header">
<img Welcome to the largest baseball site on the Web.
</div>

The header consists of a single <div> containing a banner image and the tagline for the site. I've
assigned the ID
header to the <div> so that I can use CSS to modify how it is presented. Now let's look
at the footer. It contains some basic copyright information that's found on every page.
<div id="footer">
Copyright 2003, Baseball Online.<br />
Send questions to <a href="mailto:">webmaster</a>.
</div>

Now for the navigational elements for the site. If I were going the easy route, I'd just create one
navigation file to be used on all the pages on the site, but that's not appropriate in many cases. One
purpose of navigation is to enable users to move to various areas of the site. However, another purpose
is to give users a sense of where they are on the site. So, instead of creating one navigation file to be
used everywhere, I'm going to create three navigation files, one for each section of the site.
The content of the three files follows. First is the navigation for the games section:
<div id="navigation">
<a href="/">Home</a><br />
Games<br />
file:///G|/1/0672328860/ch19lev1sec2.html (2 von 4) [19.12.2006 13:50:10]
Server-Side Includes
<a href="/teams/">Teams</a><br />
<a href="/leagues/">Leagues</a>
</div>

Here's the navigation for the teams section:
<div id="navigation">

<a href="/">Home</a><br />
<a href="/games/">Games</a><br />
Teams<br />
<a href="/leagues/">Leagues</a>
</div>

And, finally, here's the navigation for the leagues section:
<div id="navigation">
<a href="/">Home</a><br />
<a href="/games/">Games</a><br />
<a href="/teams/">Teams</a><br />
Leagues
</div>

Now that I've created all of my included files, I can stuff them in a directory called includes off of the
root directory. In this example, they'll be called
header.html, footer.html, nav_games.html, nav_teams.
html
, and nav_leagues.html. Now let's look at a real page that uses these includes:
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN'
" /><html xmlns=" xml:lang="en" lang="en">
<head>
<title>Games: A Games Page</title>
<link rel="stylesheet" type="text/css" href="/includes/styles.css" />
</head>
</head>
<body>
<! #include virtual="/includes/header.html" >
<! #include virtual="/includes/nav_games.html" >
<div id="content">This is the content for a games page.</div>

<! #include virtual="/includes/footer.html" >
</body>
</html>

As you can see, the page I created consists mainly of includes. There are a few other things to note as
well. Both in the includes and in the main page, there are no tags that modify how the data is
presented. Instead, I just put everything inside
<div> tags with IDs. The linked style sheet in this
document contains all the style rules for the page, and controls the layout of the entire page. Here's the
source for the page once all the included files have been included by the web server:
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN'
" /><html xmlns=" xml:lang="en" lang="en">
file:///G|/1/0672328860/ch19lev1sec2.html (3 von 4) [19.12.2006 13:50:10]
Server-Side Includes
<head>
<title>Games: A Games Page</title>
<link rel="stylesheet" type="text/css" href="/includes/styles.css" />
</head>
</head>
<body>
<div id="header">
<img src="header.gif" alt="Baseball Online" /><br />
Welcome to the largest baseball site on the Web.
</div>
<div id="navigation">
<a href="/">Home</a><br />
Games<br />
<a href="/teams/">Teams</a><br />
<a href="/leagues/">Leagues</a>
</div>

<div id="content">This is the content for a games page.</div>
<div id="footer">
Copyright 2003, Baseball Online.<br />
Send questions to <a href="mailto:">webmaster</a>.
</div>
</body>
</html>



file:///G|/1/0672328860/ch19lev1sec2.html (4 von 4) [19.12.2006 13:50:10]
Using Apache Access Control Files


Using Apache Access Control Files
Apache is the most popular web server, and is especially popular among ISPs that provide web hosting.
For that reason, when I discuss features of web servers, I'm going to discuss Apache. You can apply the
general techniques described here to any web server, but the specifics will apply only to Apache. Under
Apache, assuming the server administrator has given you the right to do so, you can set up access
control files that you can use to manage access to your directories, along with a lot of other things.
These days, many kinds of server configuration directives can be used on a per-directory basis from the
access file.
The access control file is generally named
.htaccess. It can actually be named anything that the server
administrator chooses, but
.htaccess is the default, and there's really no good reason to change it.
Because the filename begins with a period, it's a hidden file under UNIX. This keeps it from cluttering
things up when you're looking for content files in a directory.
Apache configuration directives begin with the directive, and the rest of the line consists of the
parameters associated with the directive. They're entered one per line. The format is usually something

like this:
Directive valueForDirective

Sometimes the configuration directives are slightly more complex, but that's the general format. The
first type of configuration I'll explain how to manipulate is actual access to the pages in the directory
(and its subdirectories).
Managing Access to Pages
Controlling access to pages can be somewhat complex, mainly because Apache's access control system
is very flexible. First, let's look at the access control directives themselves. The four you need to pay
attention to are
allow, deny, require, and order. The allow and deny directives enable you to control
access to pages based on the IP address or domain name of the computer the visitor is using. Let's say
you want to disallow all users from
samspublishing.com (meaning that they're using a computer on the
samspublishing.com network) from some pages on your site. You could just stick
deny from samspublishing.com

in your .htaccess file. These directives match parts of hostnames, so even if the user's hostname is
firewall.samspublishing.com, he'll still be denied. By the same token, you can deny based on IP address:
deny from 192.168.1

In this case, anyone on the network 192.168.1.* would be denied. You can be as restrictive as you
want. You could create a directive like this, if you wanted:
deny from com
file:///G|/1/0672328860/ch19lev1sec3.html (1 von 4) [19.12.2006 13:50:11]
Using Apache Access Control Files

Needless to say, this would prevent anyone on a .com network from viewing your pages. That's pretty
harsh. If you're not careful, you can restrict everyone from seeing your pages. If that's what you intend
to do, you can just use this directive:

deny from all

Why would you want to do that? Well, it makes more sense when combined with two other directives:
order and allow. Using order, you can specify the order in which deny and allow rules are applied. allow
is just like
deny, except that it allows users that meet the rule you specify to see the pages. So, you can
write rules like this:
order deny, allow
deny from all
allow from samspublishing.com

This restricts use of your pages to only people on the samspublishing.com network. Based on the order
directive, the deny rule is applied first, shutting out everyone. Then if the user meets your allow rule,
she's allowed in. The last directive in this family is
require. This directive, rather than basic access on
how the user's machine identifies itself, is used to require user authentication. Before you can use it,
you need to set a few things up.
First, you'll need to create a file containing a list of usernames and passwords that can be used to
access your site. Apache helpfully provides a tool to create these files, called
htpasswd. It's invoked in
the following manner:
htpasswd -c /usr/local/apache/passwords account

The arguments are as follows: the flag -c indicates that the password file should be created if it doesn't
already exist. The next argument,
/usr/local/apache/passwords, is the name of the password file. The
last argument is the name of the account you want to create. The program will then ask you to type the
password for the account and confirm it. Once you've done so, the account is created, along with the
password file. At that point, you can add more accounts to your file by repeatedly running
htpasswd

(without the
-c flag) and passing in new account names each time. The reason you can't just create a
text file in a text editor is that the passwords are encrypted when they're saved in the file.
htpasswd
takes care of that.
You can also create groups of users by creating a group file. To create this file, just use your favorite
text editor and use the following format:
groupname: account1 account2 account3

Substitute groupname with a group name of your own choosing, such as managers, and then list all the
accounts from your password file that are members of the group. Once you've set up your password file
and (optionally) your group file, you're ready to start using the
require directive. To set up what's
referred to as an authentication realm, the following directives are used:
● AuthType The authentication scheme to use. Except in rare circumstances, you'll use Basic here.
file:///G|/1/0672328860/ch19lev1sec3.html (2 von 4) [19.12.2006 13:50:11]
Using Apache Access Control Files
● AuthName The name of the realm. This name will be displayed when the user is prompted to log in.
● AuthUserFile The path of the password file you created.
● AuthGroupFile The path to the group file, if there is one.
Now let's look at how these are used in the file:
AuthType Basic
AuthName "Administrator Files"
AuthUserFile /usr/local/apache/passwords
AuthGroupFile /usr/local/apache/groups

Once you've set up the authentication realm, you can start using require directives to specify who's
allowed to see the pages and who isn't. The format for
require directives is as follows:
require group administrators

require user fred bob jim betty

First, you specify whether the require directive refers to users or groups, and then you include a list of
usernames or group names. If you included the previous directives in your
.htaccess files, the users
fred, bob, jim, and betty would be able to access the pages, along with any users in the administrators
group.
Redirecting Users
Although .htaccess files were once associated strictly with access control, their capabilities were
eventually expanded to encompass nearly all of the configuration directives for Apache. There's a full list
of configuration directives for Apache 1.3 at
/>If you're using Apache 2.0, you can use
/>I want to talk about two in particular:
Redirect and RedirectMatch. First, let's talk a bit about
redirection. Redirecting users from one URL to another is all too common. For example, let's say you
have a directory called
aboutus on your website, and you want to move everything to a directory called
about. One common way of handling things so that your users don't get a dreaded 404 Not Found error
when they go to the old URL is to put an
index.html file in that directory that looks like this:
<html>
<head>
<title>Moved</title>
<meta http-equiv="refresh" content="1; url= />
</head>
<body>
<p>This page has moved to a
<a href="/about/">new location</a>.</p>
</body>
</html>

The <meta> tag basically tells the browser to wait one second and then proceed to the URL specified. The
content on the page is there just to handle the rare case in which the user's browser doesn't do what
file:///G|/1/0672328860/ch19lev1sec3.html (3 von 4) [19.12.2006 13:50:11]