| <?xml version="1.0" encoding="UTF-8"?> |
| <!-- |
| Copyright 1999-2005 The Apache Software Foundation |
| |
| Licensed under the Apache License, Version 2.0 (the "License"); |
| you may not use this file except in compliance with the License. |
| You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| |
| <!--+ |
| | This is the 'heart' of Cocoon. The sitemap maps URI space to |
| | resources. It consists basicaly of two parts: components and |
| | pipelines. Pipelines are made out of components. There is such a |
| | vast number of components available that it would be impossible to |
| | describe them here, please refer to the accompanying |
| | documentation. For specific components, have a look also at the |
| | javadocs for them. Most pipelines are present to demonstrate some |
| | feature or technique, often they are explained in more detail in |
| | the accompanying documentation. The sitemaps which come with each |
| | sample and each block will help to explain. |
| | |
| | CVS $Id$ |
| +--> |
| <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0"> |
| |
| <!-- =========================== Components ================================ --> |
| |
| <map:components> |
| |
| <!-- include some additional components --> |
| <map:include dir="context://WEB-INF/sitemap-additions" pattern="*.xconf"/> |
| |
| </map:components> |
| |
| |
| <!-- =========================== Views =================================== --> |
| |
| <!--+ |
| | Views provide different, well, views to resources. Views are |
| | orthogonal to pipelines. Please refer to the docs. |
| | |
| | It would be wise to disable any unneeded views in a |
| | production environment in order to avoid exposing data |
| | that you may not necessarily wish to. |
| +--> |
| <map:views> |
| <map:view from-label="content" name="content"> |
| <map:serialize type="xml"/> |
| </map:view> |
| |
| <map:view from-label="content" name="pretty-content"> |
| <map:transform src="stylesheets/system/xml2html.xslt"/> |
| <map:serialize type="html"/> |
| </map:view> |
| |
| <map:view from-position="last" name="links"> |
| <map:serialize type="links"/> |
| </map:view> |
| </map:views> |
| |
| |
| <!-- =========================== Resources ================================= --> |
| |
| <!--+ |
| | Resources are pipeline fragments that may be used from different |
| | pipeline fragments. For our needs, they behave exactly like |
| | pipelines, only that they are not accessible from outside. |
| | Hence I will explain what's inside below for pipelines. |
| +--> |
| <map:resources> |
| </map:resources> |
| |
| |
| <!-- ========================== Action sets ================================ --> |
| |
| <!--+ |
| | Action sets group actions together. If some actions are often used |
| | together in pipeline fragments, it's easier to group them and refer |
| | to the group. For more info, please see the docs. |
| +--> |
| <map:action-sets> |
| </map:action-sets> |
| |
| |
| <!-- =========================== Pipelines ================================= --> |
| |
| <!--+ |
| | Pipelines. The beef. Pipelines specify how the processing of your |
| | content is done. Usually, a pipeline consists of several fragments |
| | that specify the generation, transformation, and serialization of |
| | SAX events. |
| | |
| | Processing is done in two steps: |
| | |
| | 1) The top level elements are executed in order of appearance until |
| | one signals success. These top level elements are usually |
| | matchers. |
| | |
| | Other components are called depth-first to determine what |
| | fragments make up the processing pipeline. When a component |
| | fails, no nested components are called but the next component on |
| | the same level. |
| | |
| | 2) Once it is determined which generator, which transformers and |
| | wich serializer is used, these components are executed. During |
| | this, the pipeline may not be changed. |
| | |
| | You may have as many pipelines in your sitemap as you like. |
| +--> |
| <map:pipelines> |
| |
| <map:component-configurations> |
| <global-variables> |
| <!--+ |
| | Define global parameters here: |
| | <skin>my_skin</skin> |
| | ... |
| | You can access them by {global:*name*}, e.g. {global:skin}. |
| | These values are inherited into sub-sitemaps and can |
| | be extended there. |
| +--> |
| </global-variables> |
| </map:component-configurations> |
| |
| <!-- main pipeline --> |
| <map:pipeline> |
| |
| <!-- welcome page --> |
| <map:match pattern=""> |
| |
| <!--+ |
| | Start generating SAX events inside the pipeline. In this case, |
| | since no "type" attribute is specified, the default generator |
| | is used and this is a regular XML parser that reads the |
| | given file from the URL included in the "src" attribute and |
| | sends the events produced by the parser down the pipeline to |
| | be processed by the next stage. |
| +--> |
| <map:generate src="welcome.xml"/> |
| |
| <!--+ |
| | This transformer gets the input SAX events and transforms them |
| | using the default transformer (the XSLT transformer) thus |
| | applying the XSLT stylesheet indicated in the "src" attribute |
| | and sending the output down the pipeline to be processed by the |
| | next stage. |
| +--> |
| <map:transform src="welcome.xslt"> |
| <map:parameter name="contextPath" value="{request:contextPath}"/> |
| </map:transform> |
| |
| <!--+ |
| | The serializer concludes the SAX events journey into the pipeline |
| | since it serializes the events it receives into a representation |
| | depending on the serializer type. Here we choose the "XHMTL" |
| | serializer, which will produce an XHTML representation of the |
| | SAX stream. |
| +--> |
| <map:serialize type="xhtml"/> |
| </map:match> |
| |
| <!-- FIXME Remove later --> |
| <map:match pattern="v"> |
| <map:generate type="virtual"/> |
| <map:serialize type="xhtml"/> |
| </map:match> |
| |
| <!--+ |
| | The default matching is also capable of matching more than a |
| | single request by the use of 'wildcards'. There are two kinds of |
| | wildcards: |
| | |
| | "*" means "anything that does not contain a path separator" |
| | "**" means "anything including path separators" |
| | |
| | The tokens matched by the wildcards are passed over as sitemap |
| | variables. Those variables can be accessed using the '{...}' syntax |
| | inside the attributes. The URI-matching tokens are associated to |
| | numbered variables, as shown in the following match that processes all |
| | the GIF images that are located in the 'images/' URL space but |
| | not in any deeper levels. Note how requesting "images/logo.gif" |
| | triggers the matcher to create the token {1} = 'logo' which is later |
| | expanded into the src="" attribute of the reader, indicating |
| | what file it has to read. |
| +--> |
| |
| <!-- images --> |
| <map:match pattern="images/*.gif"> |
| <map:read src="resources/images/{1}.gif" mime-type="image/gif"/> |
| </map:match> |
| |
| <!-- CSS stylesheets --> |
| <map:match pattern="styles/*.css"> |
| <map:read src="resources/styles/{1}.css" mime-type="text/css"/> |
| </map:match> |
| |
| <!-- JavaScript scripts --> |
| <map:match pattern="scripts/*.js"> |
| <map:read src="resources/scripts/{1}.js" mime-type="text/javascript"/> |
| </map:match> |
| |
| <!-- favicon --> |
| <map:match pattern="**favicon.ico"> |
| <map:read mime-type="image/x-icon" src="resources/icons/cocoon.ico"/> |
| </map:match> |
| |
| <!--+ |
| | mount user directories |
| | |
| | The location of user directories depends heavily on the operating |
| | system used. Uncomment the one below that suits your environment. |
| | |
| | NOTE: you might want to comment out the entire section for a |
| | production environment. |
| +--> |
| <map:match pattern="~*/**"> |
| <!-- unix --> |
| <map:mount src="/home/{1}/public_html/" uri-prefix="~{1}"/> |
| <!-- macosx --> |
| <!--map:mount src="/Users/{1}/Sites/" uri-prefix="~{1}"/--> |
| <!-- win32 --> |
| <!--map:mount src="/Documents and Settings/{1}/My Documents/My Website/" uri-prefix="~{1}"/--> |
| </map:match> |
| |
| <!--+ |
| | Redirect to the user directory if the ending slash is missing |
| | Cocoon doesn't do automatic translation of URLs because we consider it |
| | a bad practice. http://blah/something/ and http://blah/something |
| | effectively locate different web resources and the act of mapping |
| | them to the same system resources is your concern, not Cocoon's. |
| | Note that some stupid browsers (IE, for example) believe the opposite |
| | and will drop the ending slash when you bookmark a web resource |
| | so be aware of this issue and plan your URL-space carefully. |
| +--> |
| <map:match pattern="~*"> |
| <map:redirect-to uri="{0}/"/> |
| </map:match> |
| |
| <!--+ |
| | Map the API documentation. |
| +--> |
| <map:match pattern="api/**"> |
| <map:read src="api/{1}"/> |
| </map:match> |
| |
| <!--+ |
| | Find a match in the "mount-table.xml" file, if present. It allows to mount other |
| | directories without touching this main sitemap (and thus loosing changes on rebuild). |
| | |
| | Note that other mount-tables can be added here using the xpatch ant task |
| | (see src/confpatch/mount-table.xmap) |
| +--> |
| <!-- |
| Disabled while working on OSGI stuff, this wouldn't work anyway |
| (due to the ../) and it causes an NPE in the MountTableMatcher |
| <map:match type="mount-table" pattern="../../mount-table.xml"> |
| <map:mount src="{src}" uri-prefix="{uri-prefix}"/> |
| </map:match> |
| --> |
| |
| <!--+ |
| | Mount everything else by calling the sitemap.xmap file located |
| | in the requested folder. |
| +--> |
| <map:match pattern="*/**"> |
| <map:mount src="{1}/" uri-prefix="{1}"/> |
| </map:match> |
| |
| <!--+ |
| | At the very end of a pipeline, you can catch the errors triggered |
| | by the pipeline execution. The error handler is an internal sitemap |
| | component that, when triggered by an error, takes over the normal |
| | pipeline execution. |
| | You can here use the "notifying" generator that produces an XML |
| | representation and further manipulate this document for presentation |
| | on screen. |
| | You can also use any other generator if you don't want the |
| | error to be displayed on screen. The "exception" selector can help |
| | you to define different screens for different error types. |
| +--> |
| <map:handle-errors> |
| <map:select type="exception"> |
| |
| <map:when test="not-found"> |
| <map:generate type="exception"/> |
| <map:transform src="stylesheets/system/exception2html.xslt"> |
| <map:parameter name="contextPath" value="{request:contextPath}"/> |
| <map:parameter name="realPath" value="{realpath:}"/> |
| <map:parameter name="pageTitle" value="Resource not found"/> |
| </map:transform> |
| <map:serialize status-code="404"/> |
| </map:when> |
| |
| <map:when test="invalid-continuation"> |
| <map:generate type="exception"/> |
| <map:transform src="stylesheets/system/exception2html.xslt"> |
| <map:parameter name="contextPath" value="{request:contextPath}"/> |
| <map:parameter name="realPath" value="{realpath:}"/> |
| <map:parameter name="pageTitle" value="Invalid Continuation"/> |
| </map:transform> |
| <map:serialize status-code="404"/> |
| </map:when> |
| |
| <map:otherwise> |
| <map:generate type="exception"/> |
| <map:transform src="stylesheets/system/exception2html.xslt"> |
| <map:parameter name="contextPath" value="{request:contextPath}"/> |
| <map:parameter name="realPath" value="{realpath:}"/> |
| </map:transform> |
| <map:serialize status-code="500"/> |
| </map:otherwise> |
| </map:select> |
| |
| </map:handle-errors> |
| </map:pipeline> |
| </map:pipelines> |
| |
| </map:sitemap> |
