CVS: Tapestry/doc/src/UsersGuide configuration.xml,1.1.2.1,1.1.2.2 TapestryUsersGuide.xml,1.1.2.1,1.1.2.2
Howard Lewis Ship <[email protected]>
| Newsgroups | gmane.comp.java.tapestry.cvs |
|---|---|
| Message-ID | <[email protected]> |
Update of /cvsroot/tapestry/Tapestry/doc/src/UsersGuide
In directory sc8-pr-cvs1:/tmp/cvs-serv3722/doc/src/UsersGuide
Modified Files:
Tag: hship-2-3
configuration.xml TapestryUsersGuide.xml
Log Message:
Continue work on UsersGuide
Index: configuration.xml
===================================================================
RCS file: /cvsroot/tapestry/Tapestry/doc/src/UsersGuide/Attic/configuration.xml,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -C2 -d -r1.1.2.1 -r1.1.2.2
*** configuration.xml 22 Dec 2002 13:47:58 -0000 1.1.2.1
--- configuration.xml 27 Dec 2002 22:50:38 -0000 1.1.2.2
***************
*** 8,13 ****
<para>
! .... what goes into the web.xml ...
</para>
</section> <!-- configuration.deployment-descriptor -->
--- 8,132 ----
<para>
! All Tapestry applications make use of the &ApplicationServlet; class as their
! servlet; it is rarely necessary to create a subclass.
</para>
+
+
+ <example>
+ <title>Virtual Library Deployment Descriptor</title>
+ <programlisting>
+ <?xml version="1.0"?>
+ <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
+ "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
+ <web-app>
+ <display-name>Tapestry Virtual Library Demo</display-name>
+ <servlet>
+ <servlet-name>vlib</servlet-name> <co id="configuration.web.servlet-name"/>
+ <servlet-class>net.sf.tapestry.&ApplicationServlet;</servlet-class> <co id="configuration.web.servlet-class"/>
+ <init-param>
+ <param-name>net.sf.tapestry.application-specification</param-name> <co id="configuration.web.spec-path"/>
+ <param-value>/net/sf/tapestry/vlib/Vlib.application</param-value>
+ </init-param>
+ <load-on-startup>0</load-on-startup>
+ </servlet>
+
+ <!-- The single mapping used for the Virtual Library application -->
+
+ <servlet-mapping>
+ <servlet-name>vlib</servlet-name>
+ <url-pattern>/app</url-pattern> <co id="configuration.web.url"/>
+ </servlet-mapping>
+
+ <session-config>
+ <session-timeout>15</session-timeout>
+ </session-config>
+
+ <welcome-file-list>
+ <welcome-file>index.html</welcome-file>
+ </welcome-file-list>
+ </web-app>
+ </programlisting>
+ </example>
+
+ <calloutlist>
+ <callout arearefs="configuration.web.servlet-name">
+ <para>
+ The servlet name may be used when locating the application specification (though
+ not in this example).
+ </para>
+ </callout>
+ <callout arearefs="configuration.web.servlet-class">
+ <para>
+ The servlet class is nearly always &ApplicationServlet;. There's rarely
+ a need to create a subclass; Tapestry has many hooks for extending the
+ application.
+ </para>
+ </callout>
+ <callout arearefs="configuration.web.spec-path">
+ <para>
+ The Virtual Library application stores its specification on the classpath, rather
+ than under &WEB-INF;, so it is necessary to provide the complete
+ path to the specification.
+ </para>
+ </callout>
+ <callout arearefs="configuration.web.url">
+ <para>
+ The servlet is mapped to <filename>/app</filename> within the context. The context
+ itself has a path, determined by the application server, but typically
+ <filename>/vlib</filename>. The client web browser will see the Tapestry application
+ as <filename>http://<replaceable>host</replaceable>/vlib/app</filename>.
+ </para>
+
+ <para>
+ Using <filename>/app</filename> as the URL is a common convention when creating
+ Tapestry applications, but is not a requirement.
+ </para>
+ </callout>
+ </calloutlist>
+
+ <para>
+ On initialization, the Tapestry servlet will locate its
+ application specification; a file that identifies details about the
+ application, the pages and components within it, and any
+ component libraries it uses. Tapestry provides a great deal of
+ flexibility on where the specification is stored; trivial Tapestry
+ applications can operate without an application specification.
+ </para>
+
+ <para>
+ Prior to release 2.4, application specifications had to be stored on the classpath. This
+ is maintained for backwards compatibility. In modern applications, the specification is
+ stored under &WEB-INF;. In fact, Tapestry performs a search to find the specification:
+ </para>
+
+ <orderedlist>
+ <listitem>
+ <para>
+ On the classpath, as defined by the <literal>net.sf.tapestry.application-specification</literal>
+ configuration parameter.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ As <filename>/WEB-INF/<replaceable>name</replaceable>/<replaceable>name</replaceable>.application</filename>.
+ The <replaceable>name</replaceable> is the servlet name. This location
+ is only used in the rare case of a single WAR containing multiple Tapestry
+ applications.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ As <filename>/WEB-INF/<replaceable>name</replaceable>.application</filename>.
+ Again, <replaceable>name</replaceable> is the
+ servlet name. This is the standard scenario.
+ </para>
+ </listitem>
+ </orderedlist>
+
+ <para>
+ If the application specification still can not be found, then an empty, "stand in"
+ application specification is used.
+ </para>
+
</section> <!-- configuration.deployment-descriptor -->
Index: TapestryUsersGuide.xml
===================================================================
RCS file: /cvsroot/tapestry/Tapestry/doc/src/UsersGuide/Attic/TapestryUsersGuide.xml,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -C2 -d -r1.1.2.1 -r1.1.2.2
*** TapestryUsersGuide.xml 22 Dec 2002 13:47:58 -0000 1.1.2.1
--- TapestryUsersGuide.xml 27 Dec 2002 22:50:38 -0000 1.1.2.2
***************
*** 64,67 ****
--- 64,69 ----
+ <!ENTITY WEB-INF '<filename>WEB-INF</filename>'>
+
]>
<!-- Conventions:
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf