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. |
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" |
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 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.