Application Specification

The application specification is used to identify the name of the application, the engine class for the application, the details of each page in the application, and to set up aliases for commonly used components within the application.

The application specification is loaded when the application servlet is initialized. It defines all pages within the application (except for the four pages automatically provided by the framework: Exception, Inspector, StaleSession and StaleLink). It allows component aliases to be defined for commonly used components.

Note

Both the application and component specifications use the same DTD. As with component specifications, there is an older, more verbose version of the DTD which is not described here.

<application> element

The application specification begins with an XML header:

Figure 6.3. Application specification: <application> element

<?xml version="1.0"?>
<!DOCTYPE application PUBLIC 
  "-//Howard Ship//Tapestry Specification 1.1//EN"
  "http://tapestry.sf.net/dtd/Tapestry_1_1.dtd">


<application
  name="name" 1
  engine-class="engine-class"> 2
  [ <description ...> ...] 3
  [ <property ...> ...] 4
  [ <page ...> ...] 5
  [ <component-alias ...> ...]
</application>

1

Each Tapestry application should have a unique, descriptive name. This name is used, in a few places, to store information in the HttpSession and ServletContext; if a single web application (WAR file) contains multiple Tapestry applications, it is imperative that each has a unique name.

2

Specifies the Java class to instantiate as the application engine.

3

Applications, like components and parameters, may have a (localized) description.

4

Applications may have additional properties. This is most commonly used to specify the class to instantiate as the visit object (com.primix.tapestry.visit-class).

<page> element

The application specification will include one <page> element for each page in the application.

Figure 6.4. Application Specification: <page> element

<page
  name="name"
  specification-path="specification-path"/>

Each page in the application must have a unique name. Names may contain letters, numbers, underscores, dashes and periods.

For each page, the complete path to the page's component specification is specified. For example /com/skunkworx/skunkapp/Home.jwc.

Typically, the name of the page will match the name of the component; the logical name Home will map to /com/skunkworx/skunkapp/Home.jwc and be implemented by class com.skunkworx.skunkapp.Home. This is not a hard and fast rule, it may make sense to use different names; for example, a multi-page wizard may show the relationship between the pages using a name like WizardName.PageName. In other cases, naming conflicts can be eliminated by varying the name of the page's logical name or component.

<component-alias> element

Component aliases are used to provide short names for commonly used components within an application. All the components provided with Tapestry have predefined component aliases, which may not be overriden.

Figure 6.5. Application Specification: <component-alias> element

<component-alias
  type="type"
  specification-path="specification-path"/>

Component aliases are mostly freeform (letters, numbers and some punctuation are acceptable). A good guideline is to name the alias, the specification and the Java class the same, that is, the same as the page naming guidelines.