docs/org.eclipse.wst.webtools.doc.user/topics/ccstatic.dita

<?xml version="1.0" encoding="utf-8"?>
<!--Arbortext, Inc., 1988-2005, v.4002-->
<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
 "concept.dtd">
<concept id="ccstatic" xml:lang="en-us">
<title>Static Web projects</title>
<prolog><metadata>
<keywords><indexterm>Web projects<indexterm>static</indexterm></indexterm>
<indexterm>static Web projects<indexterm>overview</indexterm></indexterm>
</keywords>
</metadata></prolog>
<conbody>
<p>If you  want to create a content-based Web application that does not contain
any dynamic content  (such as servlets, JSP files, filters, and associated
metadata) you might prefer to create a static Web project, as opposed to a <xref
href="ccwebprj.dita" scope="peer"><desc></desc>dynamic Web project</xref>.</p>
<p>Static Web projects have the following characteristics:  <ul>
<li>a Web content folder (called WebContent) for all publishable resources,
You can change the name of this folder from the project's pop-up menu.</li>
<li>a Theme folder, the suggested directory for storing cascading style sheets
and other style-related objects.</li>
<li>the ability to define folders outside of the Web content folder, for storing
intermediate files, such as MIF files</li>
<li>a conversion path from a static Web project to a dynamic Web project.
If you decide to <xref href="twpcnvrt.dita" scope="peer"><desc></desc>convert</xref> the
project, it will be a fully-valid dynamic Web project. </li>
</ul></p>
<p>In addition, your project will still have the following features (which
are common to both static and dynamic Web projects ) : <ul>
<li>HTML syntax validation</li>
<li>a broken link fix-up wizard</li>
<li>a Web site navigation tool</li>
<li>a new server type, the Static Web server, which makes it easy to publish
static Web projects</li>
</ul> </p>
<p>The folder that a static Web project is published to is modifiable, so
that when you set the publishing "root" value (called a <i>context root</i>),
such as <codeph>/web1</codeph>, for a static project, everything in the Web
content folder will be published to the <filepath>web1</filepath> folder under
the Web server's doc root. This enables you to group Web resources on a Web
server in folders that correspond to Web projects in the workbench. When projects
defined in this way are ready for production, you can publish specific projects
directly to the doc root by changing the value to <codeph>/</codeph> and all
publishing, link fixing, and browsing will update automatically.</p>
<p>Aliases can also be used to specify a context root value. For example,
suppose that there is an alias that is defined on the target Web server, as
follows: <codeblock>Alias /scripts/ "/var/www/scripts"</codeblock>In this
example, in which the current static Web project will contain common <tm tmclass="special"
tmowner="Sun Microsystems, Inc." tmtype="tm" trademark="JavaScript">JavaScript</tm> files,
you can set the context root value to be <ph>"scripts"</ph>.  In order for
the resources in the static Web project to be published to the correct location
on the Web server, you must add this Alias mapping to the server tools instance
of the static Web server, as follows.  <ol>
<li>From the Server view, double-click on the static Web server configuration
to open the server configuration editor.<note>This assumes that you've already
defined the static Web server.</note></li>
<li>Click the <uicontrol>Configuration</uicontrol> editor tab.</li>
<li>Scroll down to the <uicontrol>Alias Path Mapping</uicontrol> section,
and add the new Alias mapping.</li>
</ol>Now that <ph>"scripts"</ph> is defined as an Alias, the Web content in
the static Web project will be published to the mapped path, <filepath>/var/www/scripts</filepath>.</p>
</conbody>
</concept>