You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by vg...@apache.org on 2007/10/26 02:43:17 UTC
svn commit: r588456 -
/cocoon/trunk/blocks/cocoon-welcome/src/main/resources/COB-INF/sitemap.xmap
Author: vgritsenko
Date: Thu Oct 25 17:43:13 2007
New Revision: 588456
URL: http://svn.apache.org/viewvc?rev=588456&view=rev
Log:
indent
Modified:
cocoon/trunk/blocks/cocoon-welcome/src/main/resources/COB-INF/sitemap.xmap
Modified: cocoon/trunk/blocks/cocoon-welcome/src/main/resources/COB-INF/sitemap.xmap
URL: http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-welcome/src/main/resources/COB-INF/sitemap.xmap?rev=588456&r1=588455&r2=588456&view=diff
==============================================================================
--- cocoon/trunk/blocks/cocoon-welcome/src/main/resources/COB-INF/sitemap.xmap (original)
+++ cocoon/trunk/blocks/cocoon-welcome/src/main/resources/COB-INF/sitemap.xmap Thu Oct 25 17:43:13 2007
@@ -32,19 +32,19 @@
+-->
<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
-<!-- =========================== Components ================================ -->
+ <!-- =========================== Components =========================== -->
- <map:components>
+ <map:components>
<!--+
| All needed components are inherited from the parent container
| configured in WEB-INF/cocoon.xconf
+-->
- </map:components>
+ </map:components>
-<!-- =========================== Views =================================== -->
+ <!-- =========================== Views ================================ -->
<!--+
| Views provide different, well, views to resources. Views are
@@ -70,7 +70,7 @@
</map:views>
-<!-- =========================== Resources ================================= -->
+ <!-- =========================== Resources ============================ -->
<!--+
| Resources are pipeline fragments that may be used from different
@@ -78,269 +78,270 @@
| pipelines, only that they are not accessible from outside.
| Hence I will explain what's inside below for pipelines.
+-->
- <map:resources>
- </map:resources>
+ <map:resources>
+ </map:resources>
-<!-- ========================== Action sets ================================ -->
+ <!-- =========================== 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.
- +-->
+ <!--+
+ | 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 ============================ -->
+
+ <!--+
+ | 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>
+ <!-- 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>
+
+ <!--+
+ | 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.
+ +-->
- <!--+
- | 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>
- <!-- main pipeline -->
- <map:pipeline>
+ <!-- Images -->
+ <map:match pattern="images/*.gif">
+ <map:read src="resource/external/images/{1}.gif" mime-type="image/gif"/>
+ </map:match>
+
+ <!-- CSS stylesheets -->
+ <map:match pattern="styles/*.css">
+ <map:read src="resource/external/styles/{1}.css" mime-type="text/css"/>
+ </map:match>
+
+ <!-- JavaScript scripts -->
+ <map:match pattern="scripts/*.js">
+ <map:read src="resource/external/scripts/{1}.js" mime-type="text/javascript"/>
+ </map:match>
+
+ <!-- Favicon -->
+ <map:match pattern="**favicon.ico">
+ <map:read mime-type="image/x-icon" src="resource/external/icons/cocoon.ico"/>
+ </map:match>
- <!-- welcome page -->
- <map:match pattern="">
+ <!--+
+ | 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>
<!--+
- | 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.
+ | 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:generate src="welcome.xml"/>
+ <map:match pattern="~*">
+ <map:redirect-to uri="{0}/"/>
+ </map:match>
<!--+
- | 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 the API documentation.
+-->
- <map:transform src="welcome.xslt">
- <map:parameter name="contextPath" value="{request:contextPath}"/>
- </map:transform>
+ <map:match pattern="api/**">
+ <map:read src="api/{1}"/>
+ </map:match>
<!--+
- | 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.
+ | 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)
+-->
- <map:serialize type="xhtml"/>
- </map:match>
+ <!--
+ 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>
+ -->
- <!--+
- | 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="resource/external/images/{1}.gif" mime-type="image/gif"/>
- </map:match>
-
- <!-- CSS stylesheets -->
- <map:match pattern="styles/*.css">
- <map:read src="resource/external/styles/{1}.css" mime-type="text/css"/>
- </map:match>
-
- <!-- JavaScript scripts -->
- <map:match pattern="scripts/*.js">
- <map:read src="resource/external/scripts/{1}.js" mime-type="text/javascript"/>
- </map:match>
-
- <!-- favicon -->
- <map:match pattern="**favicon.ico">
- <map:read mime-type="image/x-icon" src="resource/external/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>
- -->
-
- <!--+
- | Cocoon-provided client-side resources.
- | Some block's jar files (e.g. Ajax & Forms) include client-side resources
- | such as JavaScript, CSS and images. The system-level pattern below
- | fetches these resources, while allowing them to be overridden if needed
- | in the webapp's "resources" directory.
- |
- | Defining this pattern in the root sitemap avoids duplicating it in subsitemaps,
- | which reduces copy/pasting in application code and allows better client-side
- | caching by giving each resource a single URL.
- |
- | Furthermore, some Cocoon code such as the Forms-provided XSLs assume that
- | resources are available at that URL.
- |
- | The absolute path for these resources is "{request:contextPath}/_cocoon/resources"
- +-->
- <map:match pattern="_cocoon/resources/*/**">
- <map:select type="resource-exists">
- <map:when test="resources/{1}/{2}">
- <map:read src="resources/{1}/{2}"/>
- </map:when>
- <!-- For Cocoon development, read directly from source directories
- <map:when test="../../src/blocks/{1}/java/org/apache/cocoon/{1}/resources/{2}">
- <map:read src="../../src/blocks/{1}/java/org/apache/cocoon/{1}/resources/{2}"/>
+ <!--+
+ | Cocoon-provided client-side resources.
+ | Some block's jar files (e.g. Ajax & Forms) include client-side resources
+ | such as JavaScript, CSS and images. The system-level pattern below
+ | fetches these resources, while allowing them to be overridden if needed
+ | in the webapp's "resources" directory.
+ |
+ | Defining this pattern in the root sitemap avoids duplicating it in subsitemaps,
+ | which reduces copy/pasting in application code and allows better client-side
+ | caching by giving each resource a single URL.
+ |
+ | Furthermore, some Cocoon code such as the Forms-provided XSLs assume that
+ | resources are available at that URL.
+ |
+ | The absolute path for these resources is "{request:contextPath}/_cocoon/resources"
+ +-->
+ <map:match pattern="_cocoon/resources/*/**">
+ <map:select type="resource-exists">
+ <map:when test="resources/{1}/{2}">
+ <map:read src="resources/{1}/{2}"/>
+ </map:when>
+ <!-- For Cocoon development, read directly from source directories
+ <map:when test="../../src/blocks/{1}/java/org/apache/cocoon/{1}/resources/{2}">
+ <map:read src="../../src/blocks/{1}/java/org/apache/cocoon/{1}/resources/{2}"/>
</map:when>
- -->
- <map:otherwise>
- <map:read src="resource://org/apache/cocoon/{1}/resources/{2}"/>
- </map:otherwise>
- </map:select>
- </map:match>
+ -->
+ <map:otherwise>
+ <map:read src="resource://org/apache/cocoon/{1}/resources/{2}"/>
+ </map:otherwise>
+ </map:select>
+ </map:match>
- <!-- FIXME: It's a simple work-around -->
- <map:match pattern="blocks/**">
- <map:redirect-to uri="{1}/" global="true"/>
- </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/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/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/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>
+ <!-- FIXME: It's a simple work-around -->
+ <map:match pattern="blocks/**">
+ <map:redirect-to uri="{1}/" global="true"/>
+ </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>
+
+ <!--+
+ | In every 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/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/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/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>