You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by il...@apache.org on 2012/04/24 14:33:14 UTC
svn commit: r1329674 [4/10] - in /cocoon/trunk/site/cocoon-core-site: ./
core/ core/2.2/ core/2.2/src/ core/2.2/src/site/
core/2.2/src/site/resources/ core/2.2/src/site/resources/images/
core/2.2/src/site/xdoc/ src/site/ src/site/resources/ src/site/re...
Added: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1379_1_1.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1379_1_1.xml?rev=1329674&view=auto
==============================================================================
--- cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1379_1_1.xml (added)
+++ cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1379_1_1.xml Tue Apr 24 12:33:07 2012
@@ -0,0 +1,259 @@
+<?xml version="1.0" encoding="UTF-8"?><!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you 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.
+ --><document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/XDOC/2.0" xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd"><properties><title>Cocoon Core - Error Handling</title><author email="cocoon-docs@apache.org">Apache Cocoon Documentation Team</author></properties><body>
+ <div id="contentBody"><div id="bodyText"><h1 class="docTitle">Error Handling</h1><h1>Error Handling</h1><p>During the execution of a Cocoon pipeline exceptions may occur within the
+involved components like generators, transformers etc. There are two
+possibilities to deal with them: The one would be not to handle them explicitly
+in the sitemap, which causes them to be logged and a default Cocoon error page
+to be displayed in the browser. The second is to define an error handling by
+using the sitemap tag <map:handle-errors>. Therein you are able to define
+any pipeline, that is executed in case of an exception occurred and displays an
+appropriate page.</p><section name="ExceptionSelector" style="background:none;padding:0;"/><p>The ExceptionSelector allows to realize conditional error handling within
+<map:handle-errors>-tags depending on the type of the occurred exception.
+Each exception is configured centrally at the selector in the sitemap by
+associating a symbolic name to its class.</p><p>Furthermore it is possible to define, what exceptions are to be "unrolled".
+This means, that if an exception has been rethrown embedded in another
+exception, this original exception can be considered for choosing the correct
+error handling.</p><p>Example:</p><pre>
+<map:selector name="exception" src="org.apache.cocoon.selection.ExceptionSelector">
+ <exception name="processing" class="ProcessingException" unroll="true"/>
+ <exception name="sax" class="SAXException"/>
+ <exception name="application" class="ApplicationException"/>
+</map:selector>
+...
+<map:pipeline>
+ <map:match pattern="resource">
+ ...
+ </map:match>
+ <map:handle-errors>
+ <map:select type="exception">
+ <map:when test="processing">...</map:when>
+ <map:when test="sax">...</map:when>
+ <map:when test="application">...</map:when>
+ </map:select>
+ </map:handle-errors>
+</map:pipeline>
+
+ </pre><p>Let's consider the following nested exceptions to occur:</p><ol type="1">
+<li>ProcessingException ( ApplicationException ): The ProcessingException is
+unrolled, so the error pipeline for "application" will be executed.</li>
+<li>ProcessingException ( ValidationException ): Since ValidationException is
+not configured at all and therefore unknown, the ProcessingException is not
+unrolled even if unrolling is enabled. Therefore the pipeline for "processing"
+will be executed.</li>
+<li>SAXException ( ApplicationException ): The unrolling is not enabled for
+SAXException, so the pipeline for "sax" will be executed.</li>
+</ol>Please notice that the selector configuration is processed from top to bottom
+and stops at the first matching exception. Therefore the most specific classes
+must be configured first. This behaviour is the same as with Java catch
+statements.<section name="XPathExceptionSelector" style="background:none;padding:0;"/>The XPathExceptionSelector is an extension to the standard selector described
+above. It adds the possibility to configure additional conditions for each
+exception type by using JXPath expressions, that operate on the exception
+object. This configuration is also done centrally at the selector in the
+sitemap, where symbolic names are defined for all specific error situations.
+Example:<pre>
+<map:selector name="exception" src="org.apache.cocoon.selection.XPathExceptionSelector">
+ <exception name="Denied" class="AuthenticationFailure">
+ <xpath name="PasswordWrong" test="authCode=10"/>
+ <xpath name="PasswordExpired" test="errorCode=11"/>
+ <xpath name="AccessForbidden" test="errorCode&gt;11"/>
+ </exception>
+</map:selector>
+...
+<map:pipeline>
+ <map:match pattern="login">
+ ...
+ </map:match>
+ <map:handle-errors>
+ <map:select type="exception">
+ <map:when test="PasswordWrong">...</map:when>
+ <map:when test="PasswordExpired">...</map:when>
+ <map:when test="AccessForbidden">...</map:when>
+ <map:when test="Denied">...</map:when>
+ <map:otherwise>...</map:otherwise>
+ </map:select>
+ </map:handle-errors>
+</map:pipeline>
+
+ </pre><p>In this example the exception AuthenticationFailure is configured under name
+"Denied". Additionally three further conditions "PasswordWrong",
+"PasswordExpired" and "AccessForbidden" are defined by using JXPath expressions.
+Therefore instances of AuthenticationFailure are expected to have methods
+getAuthCode() and getErrorCode(). Now the error handler defined for resource
+"login" has five branches: If situation "PasswordWrong" occurs, which means that
+an AuthenticationFailure exception with auth code 10 has been thrown, the first
+error pipeline is executed. If the error code equals to 11 the second pipeline
+is executed, if it is greater that 11 the third one and all other
+AuthenticationFailure errors are handled by the fourth one. In any other error
+situation the fifth branch would be chosen.</p><p>Please notice that the selector stops when it finds the first JXPath
+expression in the configuration that matches:</p><p>Example:</p><pre>
+ <map:selector name="exception" src="org.apache.cocoon.selection.XPathExceptionSelector">
+ <exception name="application" class="ApplicationException">
+ <xpath name="error3" test="errorCode&gt;3"/>
+ <xpath name="error6" test="errorCode&gt;6"/>
+ </exception>
+ </map:selector>
+ ...
+ <map:pipeline>
+ <map:match pattern="processForm">
+ ...
+ </map:match>
+ <map:handle-errors>
+ <map:select type="exception">
+ <map:when test="error6">...</map:when> <!-- handler 1 -->
+ <map:when test="error3">...</map:when> <!-- handler 2 -->
+ </map:select>
+ </map:handle-errors>
+ </map:pipeline>
+
+ </pre><p>If an ApplicationException with error code 9 occurs, handler 2 is executed
+since error situation "error3" is configured before "error6" at the selector
+even if the expression for "error6" also evaluates to "true".</p><section name="Error Handler Hierarchy" style="background:none;padding:0;"/><p>The tag <map:handle-errors> may be attached to any <map:pipeline>
+or the <map:pipelines> tag of the root sitemap or a subsitemap. Therefore
+it is possible to define two kinds of error handlers: A default handler may be
+defined within <map:pipelines> for applying to all resources of a sitemap.
+Alternatively individual handlers may be configured for sets of resources within
+<map:pipeline>.</p><p>Example:</p><pre>
+<map:pipelines>
+ <map:pipeline name="pipe1">
+ <map:match pattern="res1">
+ ...
+ </map:match>
+ <map:handle-errors>
+ <!-- this is an individual handler for pipe1 -->
+ </map:handle-errors>
+ </map:pipeline>
+ <map:pipeline name="pipe2">
+ <map:match pattern="res2">
+ ...
+ </map:match>
+ </map:pipeline>
+ <map:pipeline name="pipe3">
+ <map:match pattern="res3">
+ ...
+ </map:match>
+ </map:pipeline>
+ <map:handle-errors>
+ <!-- this is the default handler for the whole sitemap -->
+ </map:handle-errors>
+</map:pipelines>
+
+ </pre><p>In conjunction with the ExceptionSelector resp. the XPathExceptionSelector it
+is possible to define a hierarchy of error handlers for an application. The
+behaviour then is the following: If an error occurs within a pipeline, Cocoon at
+first checks if an individual handler for this pipeline is defined. If so and it
+is able to handle the error due to its selection the processing terminates.
+Otherwise Cocoon looks for a default handler of the current sitemap. If one is
+found it is called. Now there is the same behaviour as above: If it can handle
+the exception the processing terminates otherwise the searching proceeds within
+the pipeline where the subsitemap is mounted. This goes on until the default
+handler of the root sitemap has been considered. If an error could not be
+handled at all, it is processed by the Cocoon engine in the end.</p><p>Please notice that a <map:otherwise> breaks the hierarchy since all
+errors will be handled on this level. Therefore all levels above will be called
+never.</p><p>Example:</p><pre>
+Root sitemap:
+<map:pipelines>
+ <map:pipeline>
+ <map:mount uri-prefix="sub" src="sub/"/>
+ <map:handle-errors>
+ <map:select type="exception">
+ <map:when test="resourceNotFound">...</map:when>
+ </map:select>
+ </map:handle-errors>
+ </map:pipeline>
+ <map:handle-errors>
+ <map:generate src="generalerror.htm"/>
+ <map:serialize/>
+ </map:handle-errors>
+</map:pipelines>
+
+Subsitemap:
+<map:pipelines>
+ <map:pipeline>
+ <map:match pattern="processForm">
+ ...
+ </map:match>
+ <map:handle-errors>
+ <map:select type="exception">
+ <map:when test="validation">...</map:when>
+ </map:select>
+ </map:handle-errors>
+ </map:pipeline>
+ <map:handle-errors>
+ <map:select type="exception">
+ <map:when test="application">...</map:when>
+ </map:select>
+ </map:handle-errors>
+</map:pipelines>
+
+ </pre><p>Let's consider four situations concerning the above example:</p><ol type="1">
+<li>A ValidationException occurs, because for instance the user entered an
+invalid value: The defined pipeline's handler is called. Since it has a matching
+<map:when>-section it is able to handle such an exception and therefore
+the processing is finished.</li>
+<li>An ApplicationException occurs, because for instance a database connection
+has failed: The pipeline's handler is not able to handle the exception, so next
+the subsitemap's default handler is called. It has a matching
+<map:when>-section and is therefore able to handle the exception.</li>
+<li>A ResourceNotFoundException occurs, because for instance some file is
+missing. Both the pipeline's and the subsitemaps' handlers are not able to
+handle it. Now Cocoon proceeds after the mount point of the subsitemap and finds
+its pipeline's handler next. It is able to handle a ResourceNotFoundException
+and therefore produces the output in this case.</li>
+<li>A NullPointerException occurs, because something went completely wrong in
+the application: All handlers are not configured for such an exception and so
+the root sitemaps default handler will apply to it showing a general error page.
+</li>
+</ol>When handling exceptions in error handlers one has to take care about
+recursion when working with redirects. Consider the following sitemap:Example:<pre>
+<map:pipelines>
+ <map:pipeline>
+ <map:match pattern="resource">
+ ...
+ <map:transformer type="foo"/>
+ ...
+ </map:match>
+ <map:match pattern="error">
+ ...
+ <map:transformer type="foo"/>
+ ...
+ </map:match>
+ <map:handle-errors>
+ <map:select type="exception">
+ <map:when test="connection">
+ <map:act type="redirect" src="cocoon:/error"/>
+ </map:when>
+ </map:select>
+ </map:handle-errors>
+ </map:pipeline>
+</map:pipelines>
+
+ </pre>This configuration may lead to an infinite loop: Imagine to call "resource"
+where the FooTransformer throws a ConnectionException, because the connection to
+a backend system has broken. The defined error handler will handle it and the
+used action internally redirects to resource "error". This resource itself uses
+the FooTransformer to get some data from the backend, which of cause also causes
+a ConnectionException. This is handled by the error handler, which redirects to
+resource "error" and so on. Such an infinite loop may also occur when using
+several "nested" redirects, i.e. the error handler redirects to a resource,
+which redirects to another resource, which might produce the original exception.
+When defining error handlers for an application such situation must be
+avoided. An easy rule would be: An error handling routine must never redirect to
+a resource for which the routine itself is responsible and which might produce
+the same error as just handled.</div></div>
+ </body></document>
\ No newline at end of file
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1379_1_1.xml
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1379_1_1.xml
------------------------------------------------------------------------------
svn:keywords = Date Revision Author HeadURL Id
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1379_1_1.xml
------------------------------------------------------------------------------
svn:mime-type = text/xml
Added: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1380_1_1.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1380_1_1.xml?rev=1329674&view=auto
==============================================================================
--- cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1380_1_1.xml (added)
+++ cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1380_1_1.xml Tue Apr 24 12:33:07 2012
@@ -0,0 +1,103 @@
+<?xml version="1.0" encoding="UTF-8"?><!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you 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.
+ --><document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/XDOC/2.0" xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd"><properties><title>Cocoon Core - Using Control Flow</title><author email="cocoon-docs@apache.org">Apache Cocoon Documentation Team</author></properties><body>
+ <div id="contentBody"><div id="bodyText"><h1 class="docTitle">Using Control Flow</h1><div class="note"><div><strong>Note: </strong>The concept of Control Flow is explained by using Flowscript,
+one of the available implementations.</div></div><p>The general flow of actions in an application which uses the control flow is
+as described below.</p><p>The request is received by Cocoon and passed to the sitemap for processing.
+In the sitemap, you can do two things to pass the control to the Control Flow
+layer:</p><ul>
+<li>You can invoke a JavaScript top-level function to start processing a
+logically grouped sequences of pages. Each time a response page is being sent
+back to the client browser from this function, the processing of the JavaScript
+code stops at the point the page is sent back, and the HTTP request finishes.
+Through the magic of continuations, the execution state is saved in a
+continuation object. Each continuation is given a unique string id, which could
+be embedded in generated page, so that you can restart the saved computation
+later on.</li>
+<li>To invoke a top level JavaScript function in the Control Flow, you use the
+<a href="NO_LINK"><tt><map:call
+function="[function-name]"/></tt></a> construction.</li>
+<li>To restart the computation of a previously stopped function, you use the
+<a href="NO_LINK"><tt><map:call
+continuation="..."/></tt></a> construction. This restarts the computation
+saved in a continuation object identified by the string value of the
+<tt>continuation</tt> attribute. This value could be extracted in the sitemap
+from the requested URL, from a POST or GET parameter etc. When the computation
+stored in the continuation object is restarted, it appears as if nothing
+happened, all the local and global variables have exactly the same values as
+they had when the computation was stopped.</li>
+</ul>Once the JavaScript function in the control layer is restarted, you're
+effectively inside the Control Flow. Here you have access to the request
+parameters, and to the business logic objects. The controller script takes the
+appropriate actions to invoke the business logic, usually written in Java,
+creating objects, setting various values on them etc...When the business logic is invoked, you're inside the Model. The business
+logic takes whatever actions are needed, accessing a database, making a SOAP
+request to a Web service etc. When this logic finishes, the program control goes
+back to the Control Flow.Once here, the Control Flow has to decide which page needs to be sent back to
+the client browser. To do this, the script can invoke one of the
+<a href="NO_LINK"><tt>cocoon.sendPageAndWait()</tt></a> or
+<a href="NO_LINK"><tt>cocoon.sendPage()</tt></a> functions. These
+functions take two parameters, the relative URL of the page to be sent back to
+the client, and a context object which can be accessed inside this page to
+extract various values and place them in the generated page.<p>The second argument to <tt>cocoon.sendPageAndWait()</tt> and
+<tt>cocoon.sendPage()</tt> is a context object, which can be a simple dictionary
+with values that need to be displayed by the View. More generally any Java or
+JavaScript object can be passed here, as long as the necessary get methods for
+the important values are provided.</p><p>The page specified by the URL is processed by the sitemap, using the normal
+sitemap rules. The simplest case is a <a href="NO_LINK">generator</a>
+followed by an XSLT transformation and a serializer. This page generation is
+part of the View layer. To process a page you can make use of several Cocoon
+<a href="NO_LINK">generators</a> to retrieve values from the context objects
+passed by the Control Flow.</p><p>Going back to the <tt>cocoon.sendPageAndWait()</tt> and <tt>sendPage()</tt>
+functions, there is a big difference between them. The first function will send
+the response back to the client browser, and will stop the processing of the
+JavaScript script by saving it into a continuation object. The other function,
+<tt>cocoon.sendPage()</tt> will send the response, but it will not stop the
+computation. This is useful for example when you need to exit a top-level
+JavaScript function invoked with <tt><map:call function="..."/></tt>.</p><p>The above explains how MVC could be really achieved in Cocoon with the
+control flow layer. Note that there is no direct communication between Model and
+View, everything is directed by the Control Flow by passing to View a context
+object constructed from Model data.</p><section name="Basic usage" style="background:none;padding:0;"/><p>As hinted in the previous section, an application using Cocoon's MVC approach
+is composed of three layers:</p><ul>
+<li>A JavaScript controller which implements the interaction with the client
+</li>
+<li>The business logic model which implements your application</li>
+<li>The <a href="NO_LINK">page templates</a>, which describe the content of
+the pages, and XSLT stylesheets which describe the look of the content.</li>
+</ul>In more complex applications, the flow of pages can be thought of smaller
+sequences of pages which are composed together. The natural analogy is to
+describe these sequences in separate JavaScript functions, which can then be
+called either from the sitemap, can call each other freely.An example of such an application is the user login and preferences sample
+This application is composed of four top-level JavaScript functions:<ul>
+<li><tt>login</tt>,</li>
+<li><tt>registerUser</tt>,</li>
+<li><tt>edit</tt> and</li>
+<li><tt>logout</tt>.</li>
+</ul>The entry level point in the application can be any of these functions, but
+in order for a user to use the application, (s)he must login first. Once the
+user logs in, we want to maintain the Java User object which represents the user
+between top-level function invocations.Even if you don't need complex control flow in your application, you may
+still choose to use the MVC pattern described above. You can have top- level
+JavaScript functions which obtain the request parameters, invoke the business
+logic and then call <tt>cocoon.sendPage()</tt> to generate a response page and
+return from the computation. Since there's no continuation object being created
+by this function, and no global scope being saved, there's no memory resource
+being eaten. The approach provides a clean way of separating logic and content,
+and makes things easy to follow, since you have to look at a single script to
+understand what's going on.</div></div>
+ </body></document>
\ No newline at end of file
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1380_1_1.xml
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1380_1_1.xml
------------------------------------------------------------------------------
svn:keywords = Date Revision Author HeadURL Id
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1380_1_1.xml
------------------------------------------------------------------------------
svn:mime-type = text/xml
Added: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1395_1_1.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1395_1_1.xml?rev=1329674&view=auto
==============================================================================
--- cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1395_1_1.xml (added)
+++ cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1395_1_1.xml Tue Apr 24 12:33:07 2012
@@ -0,0 +1,22 @@
+<?xml version="1.0" encoding="UTF-8"?><!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you 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.
+ --><document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/XDOC/2.0" xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd"><properties><title>Cocoon Core - ServletServiceSerializer</title><author email="cocoon-docs@apache.org">Apache Cocoon Documentation Team</author></properties><body>
+ <div id="contentBody"><div id="bodyText"><h1 class="docTitle">ServletServiceSerializer</h1><h1>Summary</h1><p>The <tt>ServletServiceSerializer</tt> POSTs its input data to a called
+service. Result of the serialization is a data returned by the called service.
+</p><h1>Basic information</h1><table class="bodyTable"><tbody><tr class="a"><th>Component type</th><td>Serializer</td></tr><tr class="b"><th>Cocoon block</th><td>core</td></tr><tr class="a"><th>Java class</th><td>org.apache.cocoon.servletservice.postable.components.ServletServiceSerializer</td></tr><tr class="b"><th>Name in Sitemap</th><td>servletService</td></tr><tr class="a"><th>Cacheable</th><td>No</td></tr></tbody></table><h1>Documentation</h1><p>No documentation available yet.</p></div></div>
+ </body></document>
\ No newline at end of file
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1395_1_1.xml
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1395_1_1.xml
------------------------------------------------------------------------------
svn:keywords = Date Revision Author HeadURL Id
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1395_1_1.xml
------------------------------------------------------------------------------
svn:mime-type = text/xml
Added: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1396_1_1.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1396_1_1.xml?rev=1329674&view=auto
==============================================================================
--- cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1396_1_1.xml (added)
+++ cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1396_1_1.xml Tue Apr 24 12:33:07 2012
@@ -0,0 +1,21 @@
+<?xml version="1.0" encoding="UTF-8"?><!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you 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.
+ --><document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/XDOC/2.0" xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd"><properties><title>Cocoon Core - ServletServiceTransformer</title><author email="cocoon-docs@apache.org">Apache Cocoon Documentation Team</author></properties><body>
+ <div id="contentBody"><div id="bodyText"><h1 class="docTitle">ServletServiceTransformer</h1><h1>Summary</h1><p>The <tt>ServletServiceTransformer</tt> POSTs its input data to a called
+service and passes the XML data returned by the service down the pipeline.</p><h1>Basic information</h1><table class="bodyTable"><tbody><tr class="a"><th>Component type</th><td>Transformer</td></tr><tr class="b"><th>Cocoon block</th><td>core</td></tr><tr class="a"><th>Java class</th><td>org.apache.cocoon.servletservice.postable.components.ServletServiceTransformer</td></tr><tr class="b"><th>Name in Sitemap</th><td>servletService</td></tr><tr class="a"><th>Cacheable</th><td>No</td></tr></tbody></table><h1>Documentation</h1><p>No documentation available yet.</p></div></div>
+ </body></document>
\ No newline at end of file
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1396_1_1.xml
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1396_1_1.xml
------------------------------------------------------------------------------
svn:keywords = Date Revision Author HeadURL Id
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1396_1_1.xml
------------------------------------------------------------------------------
svn:mime-type = text/xml
Added: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1398_1_1.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1398_1_1.xml?rev=1329674&view=auto
==============================================================================
--- cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1398_1_1.xml (added)
+++ cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1398_1_1.xml Tue Apr 24 12:33:07 2012
@@ -0,0 +1,21 @@
+<?xml version="1.0" encoding="UTF-8"?><!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you 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.
+ --><document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/XDOC/2.0" xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd"><properties><title>Cocoon Core - ServletServiceGenerator</title><author email="cocoon-docs@apache.org">Apache Cocoon Documentation Team</author></properties><body>
+ <div id="contentBody"><div id="bodyText"><h1 class="docTitle">ServletServiceGenerator</h1><h1>Summary</h1><p>The <tt>ServletServiceGenerator</tt> POSTs its input data to a called service
+and passes the XML data returned by the service down the pipeline.</p><h1>Basic information</h1><table class="bodyTable"><tbody><tr class="a"><th>Component type</th><td>Generator</td></tr><tr class="b"><th>Cocoon block</th><td>core</td></tr><tr class="a"><th>Java class</th><td>org.apache.cocoon.servletservice.postable.components.ServletServiceGenerator</td></tr><tr class="b"><th>Name in Sitemap</th><td>servletService</td></tr><tr class="a"><th>Cacheable</th><td>No</td></tr></tbody></table><h1>Documentation</h1><p>No documentation available yet.</p></div></div>
+ </body></document>
\ No newline at end of file
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1398_1_1.xml
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1398_1_1.xml
------------------------------------------------------------------------------
svn:keywords = Date Revision Author HeadURL Id
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1398_1_1.xml
------------------------------------------------------------------------------
svn:mime-type = text/xml
Added: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1399_1_1.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1399_1_1.xml?rev=1329674&view=auto
==============================================================================
--- cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1399_1_1.xml (added)
+++ cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1399_1_1.xml Tue Apr 24 12:33:07 2012
@@ -0,0 +1,52 @@
+<?xml version="1.0" encoding="UTF-8"?><!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you 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.
+ --><document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/XDOC/2.0" xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd"><properties><title>Cocoon Core - Logging configuration</title><author email="cocoon-docs@apache.org">Apache Cocoon Documentation Team</author></properties><body>
+ <div id="contentBody"><div id="bodyText"><h1 class="docTitle">Logging configuration</h1><h1>Introduction</h1><p>Cocoon uses Log4j library for logging and uses it quite extensively so log
+files can be very valuable source of information how things are performed. There
+are five standard log levels to choose in order to limit amount of information
+dumped to log files:</p><ul>
+<li>FATAL_ERROR</li>
+<li>ERROR</li>
+<li>WARN</li>
+<li>INFO</li>
+<li>DEBUG</li>
+</ul>In production environment it is reasonable to set a log level to
+<tt>ERROR</tt> or <tt>FATAL_ERROR</tt> so only very important events are logged
+(like crashes). While developing an application you would probably like to see
+much more. It's up to you to choose an approporiate log level; little
+experimantation will give you sense of each setting.<h1>Tweaking the configuration</h1>Configuration in Cocoon is handled by <a href="../../../../subprojects/configuration/1.0/spring-configurator/2.0/1304_1_1.html">Spring
+configurator</a>, go there for general information.<section name="How to set up a log level" style="background:none;padding:0;"/><div class="note"><div><strong>Note: </strong>Instructions put below assume that you have created a block
+according to this <a href="../../../../2.2/1159_1_1.html">tutorial</a>. Please refer to it, first.
+</div></div>Steps that you need to perform:<ol type="1">
+<li>
+create a <tt>properties</tt> subfolder in your block:
+
+<pre>myBlock1/src/main/resources/META-INF/cocoon/properties</pre>
+</li>
+<li>
+create a new file in that folder that should have as ending
+<tt>.properties</tt>, e.g. <tt>settings.properties</tt>
+</li>
+<li>inside that file you have to put this line if you want to set log level to
+<tt>DEBUG</tt>:<br/>
+
+<pre>org.apache.cocoon.log4j.loglevel=debug</pre>
+</li>
+</ol>That's all! Restart your webapp and you should see now a detailed log
+information in a file in:<pre>myBlock1/target/work/log/log4j.log</pre></div></div>
+ </body></document>
\ No newline at end of file
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1399_1_1.xml
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1399_1_1.xml
------------------------------------------------------------------------------
svn:keywords = Date Revision Author HeadURL Id
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1399_1_1.xml
------------------------------------------------------------------------------
svn:mime-type = text/xml
Added: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1403_1_1.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1403_1_1.xml?rev=1329674&view=auto
==============================================================================
--- cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1403_1_1.xml (added)
+++ cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1403_1_1.xml Tue Apr 24 12:33:07 2012
@@ -0,0 +1,32 @@
+<?xml version="1.0" encoding="UTF-8"?><!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you 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.
+ --><document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/XDOC/2.0" xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd"><properties><title>Cocoon Core - LogAction</title><author email="cocoon-docs@apache.org">Apache Cocoon Documentation Team</author></properties><body>
+ <div id="contentBody"><div id="bodyText"><h1 class="docTitle">LogAction</h1><h1>Summary</h1><p>A simple Action that logs a given message for a given log level.</p><h1>Basic information</h1><table class="bodyTable"><tbody><tr class="a"><th>Component type</th><td>Action</td></tr><tr class="b"><th>Cocoon block</th><td>core</td></tr><tr class="a"><th>Java class</th><td>org.apache.cocoon.acting.LogAction</td></tr><tr class="b"><th>Name in Sitemap</th><td/></tr><tr class="a"><th>Cacheable</th><td/></tr></tbody></table><h1>Documentation</h1><p>A simple Action that logs a given message for a given log level.</p><p>Parameters:</p><ul>
+<li>level (optional):Â Â Indicates the log level, defaults to 'info'</li>
+<li>console (optional): Indicates weather the message is also print to console,
+defaults to 'false'</li>
+<li>message (optional): The message to log, defaults to 'No log message given'
+</li>
+</ul>Sitemap definition:<br/>
+<map:action name="log" src="org.apache.cocoon.acting.LogAction" />Â Example use:<map:match pattern="some-resource"><p>Â <!-- do something else --></p><p>Â <map:act type="log"><br/>
+Â Â Â <map:parameter name="level" value="info" /><br/>
+Â Â Â <;map:parameter name=";message" value="Log message from sitemap action"
+/><br/>
+Â Â Â <;map:parameter name="console" value="true" /><br/>
+Â </map:act></p><p>Â <!-- do something else -->;</p><p></map:match></p></div></div>
+ </body></document>
\ No newline at end of file
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1403_1_1.xml
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1403_1_1.xml
------------------------------------------------------------------------------
svn:keywords = Date Revision Author HeadURL Id
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/1403_1_1.xml
------------------------------------------------------------------------------
svn:mime-type = text/xml
Added: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/664_1_1.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/664_1_1.xml?rev=1329674&view=auto
==============================================================================
--- cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/664_1_1.xml (added)
+++ cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/664_1_1.xml Tue Apr 24 12:33:07 2012
@@ -0,0 +1,50 @@
+<?xml version="1.0" encoding="UTF-8"?><!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you 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.
+ --><document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/XDOC/2.0" xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd"><properties><title>Cocoon Core - Basic Contracts</title><author email="cocoon-docs@apache.org">Apache Cocoon Documentation Team</author></properties><body>
+ <div id="contentBody"><div id="bodyText"><h1 class="docTitle">Basic Contracts</h1><h1>Sitemap Components</h1><p>All sitemap components follow some basic contracts, which makes learning how
+to write components a bit easier. The first and most important contract is that
+all components usable in the sitemap implement the SitemapComponent interface.
+This is the very first contract to understand and learn. We then build on each
+of the contracts a little at a time until we have the full understanding of what
+is happening between the sitemap and the components it uses. Other contracts
+that we will look at are the SitemapOutputComponent,
+CacheableProcessingComponent, Generator, Transformer, Serializer, Reader, and
+Action.</p><p>The goal of this series is to introduce you to the mechanics of the different
+components and how they are created. When applicable we will address when is a
+good time to create these components, although that is not the primary focus.
+</p><section name="Core Sitemap Contracts" style="background:none;padding:0;"/><p>The sitemap is responsible for setting up and using the components for a
+given pipeline. A pipeline consists of one or more SitemapModelComponents and a
+SitemapOutputComponent. Examples of this are a pipeline consisting of a
+Generator, some Transformers, and a Serializer. The Generator and Transformer
+interfaces implement the SitemapModelComponent while the Serializer interface
+implements the SitemapOutputComponent. The same goes for a pipeline consisting
+only of a Reader. The Reader interface implements both the SitemapModelComponent
+interface and the SitemapOutputComponent interface.</p><p>The basic progression of a request consists of the Sitemap reserving the
+components that will be used for the request. It then performs the setup that is
+necessary for the components to find the resources they use and set up any
+caching directives. Next, it executes the pipeline to produce your results.
+Lastly, it releases all the components used to process the request back to the
+respective pools.</p><section name="Extended Contracts" style="background:none;padding:0;"/><p>The particular pipeline type used can support additional contracts like
+caching. The CachingPipeline uses the CacheableProcessingComponent interface to
+determine how and when to control caching. Remember that some items in your
+system are dependent on more than the URL used to access it. For example, if you
+are navigating through a list, the important meta-information of what page you
+are on should be part of the cache so that you don't get repeated results just
+because the URL didn't really change. We'll look at that in more detail as well.
+</p></div></div>
+ </body></document>
\ No newline at end of file
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/664_1_1.xml
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/664_1_1.xml
------------------------------------------------------------------------------
svn:keywords = Date Revision Author HeadURL Id
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/664_1_1.xml
------------------------------------------------------------------------------
svn:mime-type = text/xml
Added: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/673_1_1.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/673_1_1.xml?rev=1329674&view=auto
==============================================================================
--- cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/673_1_1.xml (added)
+++ cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/673_1_1.xml Tue Apr 24 12:33:07 2012
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="UTF-8"?><!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you 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.
+ --><document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/XDOC/2.0" xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd"><properties><title>Cocoon Core - SitemapModelComponent Contracts</title><author email="cocoon-docs@apache.org">Apache Cocoon Documentation Team</author></properties><body>
+ <div id="contentBody"><div id="bodyText"><h1 class="docTitle">SitemapModelComponent Contracts</h1><h1>The SitemapModelComponent</h1><p>The SitemapModelComponent identifies the contract between the Sitemap and
+your pipeline components that create or transform information. The types of
+components that fit within this umbrella are your Generators, Transformers, and
+your Readers. It is very important to note that all components implementing this
+interface must be pooled or created on demand. This is due to the separation
+between the setup and the execution. If you don't ensure every instance of the
+component is unique within a pipeline, or across pipelines, then the setup
+process will start killing all the other setups and you will end up with serious
+race conditions. It's not that they need synchronized keywords applied to the
+methods, its that the methods have to be called in a certain order. This is by
+design. If you really think about it, due to the SAX infrastructure we would
+still need to keep them synchronized because the order of SAX events affects the
+validity of your XML document.</p><section name="Setup" style="background:none;padding:0;"/><p>The Sitemap will call the <tt>setup()</tt> method to prepare the component
+for use. This is where you start the process of getting your information ready
+to generate your results. The Sitemap provides the following information:</p><ul>
+<li>SourceResolver--to find resources within your context.</li>
+<li>Object Model--a <tt>java.util.Map</tt> that contains the request and session
+information.</li>
+<li>Source--the value of the "src" attribute in the sitemap.</li>
+<li>Parameters--the sitemap parameters passed into your component.</li>
+</ul>The setup method can throw one of three different types of exceptions which
+would abort the processing of the pipeline. These exceptions are:<ul>
+<li>ProcessingException--the preferred type of exception. Essentially wrap
+anything with one of these.</li>
+<li>SAXException--a problem reading an XML document will generate one of these.
+</li>
+<li>IOException--when you can't find a file or there is a problem with the
+filesystem.</li>
+</ul><section name="Finding Resources" style="background:none;padding:0;"/>The SourceResolver passed into your SitemapModelComponent is used to find
+other resources. It will behave with the same properties as your sitemap. So if
+you are in a mounted sitemap handling a certain segment of requests, any
+relative URLs resolved by the SourceResolver will be relative to that sitemap.
+However, the real fun comes with the types of requests we can make. Cocoon
+understands several different protocols, including embedding a call to another
+pipeline within your generated document.<div class="note"><div><strong>Note: </strong>TODO: details of working with the SourceResolver</div></div><section name="Working with the Object Model" style="background:none;padding:0;"/>The object model that your component gets to use is essentially a
+<tt>java.util.Map</tt>. So how do we find what we need to get our job done?
+After all a key for a Java Map is just an Object--it could be anything.
+Thankfully, Cocoon provides a class to help you find your information:
+<a href="http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/environment/ObjectModelHelper.html">org.apache.cocoon.environment.ObjectModelHelper</a>.
+You will be able to find the Cocoon Context, Request, and Response objects.The Context and Request objects are simplified forms of the ServletContext
+and ServletRequest objects--however they do allow Cocoon to be invoked from the
+command line as well. The Response object follows the same vein, and does not
+provide any access to the output stream. That is because it is only the
+responsibility of a SitemapOutputComponent to send the results down the output
+stream. So why provide access to the Response object at all? It is for two
+reasons: so that you can add or modify response headers before the pipeline is
+executed, or that you can signal a redirect.<section name="The Source" style="background:none;padding:0;"/>The source provided by the Sitemap is the value of the attribute "src" in the
+sitemap. For example:<pre><map:transformer type="custom" src="{1}.xsl"/>
+</pre>Will resolve the name based on the substitution values and then pass the
+resolved name to the component. Let's say we matched on the pattern "status/*"
+with the url "status/printfriendly". The Sitemap will resolve the source to
+"printfriendly.xsl" using the definition above. The source is not necessary all
+the time, although you may find it much more convenient than retrieving
+information from a request object or the parameters.<section name="Working with the Parameters" style="background:none;padding:0;"/>The parameters object allows you to pull information in much the same way as
+you would in the sitemap. The
+<a href="http://excalibur.apache.org/apidocs/org/apache/avalon/framework/parameters/Parameters.html">org.apache.avalon.framework.parameters.Parameters</a>
+object is the same as the one from the Excalibur project, and you have the same
+interface there.<div class="note"><div><strong>Note: </strong>You can get parent parameters using paths in the name. For
+example, <tt>getParameter("../mrn")</tt> will get the "mrn" value from a parent
+Parameters object.</div></div><p>The parameters are set in the sitemap using the <tt><map:parameter
+name="foo" value="bar"/></tt> to set the parameter "foo" with the value
+"bar". An example would look like this:</p><pre><map:generator type="myspecialgen" src="foo">
+ <!-- these parameters are passed in -->
+ <map:parameter name="foo" value="bar"/>
+ <map:parameter name="nav" value="{request:bar}"/>
+</map:generator>
+</pre><p>Sometimes you may find some weirdness with parameters if you are setting some
+values in flowscript and expecting to see them in your generator. In that case
+you may find it much more convenient to pass values within the Request
+attributes.</p></div></div>
+ </body></document>
\ No newline at end of file
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/673_1_1.xml
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/673_1_1.xml
------------------------------------------------------------------------------
svn:keywords = Date Revision Author HeadURL Id
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/673_1_1.xml
------------------------------------------------------------------------------
svn:mime-type = text/xml
Added: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/674_1_1.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/674_1_1.xml?rev=1329674&view=auto
==============================================================================
--- cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/674_1_1.xml (added)
+++ cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/674_1_1.xml Tue Apr 24 12:33:07 2012
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="UTF-8"?><!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you 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.
+ --><document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/XDOC/2.0" xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd"><properties><title>Cocoon Core - SitemapOutputComponent Contracts</title><author email="cocoon-docs@apache.org">Apache Cocoon Documentation Team</author></properties><body>
+ <div id="contentBody"><div id="bodyText"><h1 class="docTitle">SitemapOutputComponent Contracts</h1><h1>SitemapOutputComponent Contracts</h1><p>The SitemapOutputComponents are responsible for taking the results of a
+pipeline to the end user. The Sitemap will terminate the pipeline when it
+encounters the first instance of a SitemapOutputComponent. Just like the
+SitemapModelComponent, all implementations of this contract must be pooled for
+the same reasons. The sitemap will query the output component for the mime type
+and whether the sitemap should set the content length in the response. It will
+then provide the output component the <tt>java.io.OutputStream</tt> so you can
+send the bytes directly to the user.</p><p>It should be noted that there is no way to access any of the request,
+response, or context objects within a component that just implements this
+interface like the Serializer. The idea is to keep things simple. All your
+response attributes should have been already set, and the only responsibility at
+this point in time is to give the user what he wants--the rendered object
+(page/image/etc.).</p><section name="The Mime Type" style="background:none;padding:0;"/><p>You should always provide a mime type for the results you are serializing.Â
+It helps responsible browsers to identify how to show the information to the
+user. Do keep in mind that one of the most common browsers is a poor netizen
+and does not always respect this information. I am talking about Microsoft's
+InternetExplorer. It will first try to use the file extension of the resource
+to determine the mime type, and then if that fails it will fall back to
+respecting the mime type. For that reason it is essential that you also
+practice good netizen habits and make the file extension and the mime type
+agree. One example is the PDF document. In order for Microsoft to treat a
+result set as a PDF document you must have the url end with ".pdf" as well as
+set the mime type to "application/pdf". Internet Explorer will fail if you try
+to send the document "badhabit.xml?view=pdf" rendered as a PDF document. It is
+because the file extension ".xml" will be remapped to "text/xml" even if you set
+the mime type correctly.</p><p>It is for this reason that you may have some incorrectly configured servers
+that will work for one browser and not the other. The world would be much
+simpler if all browsers blindly accepted the mime type. Just be aware of this
+issue when you are creating your sitemap and serializing your results.</p><section name="Setting the Content Length" style="background:none;padding:0;"/><p>Most types of documents don't really care what the content length is, so it
+is usually safe to leave the results of the <tt>shouldSetContentLength()</tt>
+call to <tt>false</tt>. It should be noted that the Adobe Acrobat Reader plugin
+for Microsoft InternetExplorer has a bug that wasn't fixed until version 7. The
+bug prevents the PDF document from displaying correctly. It will look like an
+empty document or something similar. So the general rule of thumb for
+explicitly seting the content length is:</p><ul>
+<li>If it is a PDF document, always set content length (might require the
+document to be cached to get the number of bytes)</li>
+<li>If you are writing a Reader and you have the content lenght, set it.</li>
+<li>Otherwise it is safe to return false here.</li>
+</ul><section name="The Output Stream" style="background:none;padding:0;"/>There's not much to say here other than use the stream responsibly. If you
+are outputing text, ensure that it is properly encoded. If you are outputing
+binary information don't do any encoding.There is so much that can be done with a raw OutputStream, but try to keep
+things simple. Things such as zipping the results as they are sent are
+possibilities as long as the browser can handle it. There is also overhead with
+doing anything other than simply outputting your results. The more complex your
+processing the less it will be able to scale nicely.The last thing to say here is to remember to close the output stream when you
+are done.</div></div>
+ </body></document>
\ No newline at end of file
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/674_1_1.xml
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/674_1_1.xml
------------------------------------------------------------------------------
svn:keywords = Date Revision Author HeadURL Id
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/674_1_1.xml
------------------------------------------------------------------------------
svn:mime-type = text/xml
Added: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/675_1_1.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/675_1_1.xml?rev=1329674&view=auto
==============================================================================
--- cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/675_1_1.xml (added)
+++ cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/675_1_1.xml Tue Apr 24 12:33:07 2012
@@ -0,0 +1,151 @@
+<?xml version="1.0" encoding="UTF-8"?><!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you 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.
+ --><document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/XDOC/2.0" xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd"><properties><title>Cocoon Core - CacheableProcessingComponent Contracts</title><author email="cocoon-docs@apache.org">Apache Cocoon Documentation Team</author></properties><body>
+ <div id="contentBody"><div id="bodyText"><h1 class="docTitle">CacheableProcessingComponent Contracts</h1><h1>CacheableProcessingComponent Contracts</h1><p>Just about everything can be cached, so it makes sense to provide some
+controls to make sure that the user always gets valid results. There are two
+aspects to a cacheable component: the key and the validition. The key is used to
+determine within the component's scheme of things whether a result is unique.
+For example, if your generator provides dynamic information based on an ID and a
+user, you want to combine the two elements into one key. That way Cocoon can
+determine whether to use the cached information for the given ID/User
+combination or create it from scratch.</p><p>The CachingPipeline will check the component's key to see if it even has the
+information cached to begin with. Next, it will check the validity of the cached
+value if there is one. If the cache has the resource and it is valid, the
+CachingPipeline will return the cached results. If either condition is false,
+then the CachingPipeline will generate the results and cache it for later use.
+It is important to realize that only the CachingPipeline will respect the
+contracts outlined in this document.</p><section name="The Cache Key" style="background:none;padding:0;"/><p>The cache key is the single most important part of the caching
+implementation. If you don't get it right, you can introduce more load on the
+caching engine than is necessary. It is important that the cache key has the
+following attributes:</p><ul>
+<li>It must be Serializable (part of the contract of the <tt>getKey()</tt>
+method).</li>
+<li>It must be Immutable--the key is used as a lookup value.</li>
+<li>It must be Unique within the space of the component (i.e. the key "1" for
+<tt>MyCacheableComponent </tt>must be for the same resource every time, but we
+don't have to worry about the key "1" for YourCacheableComponent).</li>
+<li>The <tt>equals()</tt> and <tt>hashCode()</tt> methods must
+be consistent (i.e. if two keys are equal, the hashCode must also be equal).
+</li>
+</ul>Thankfully there is a perfectly suitable object that satisfies these
+obligations from Java's core: <tt>java.lang.String</tt>. You can also use your
+own specific key objects provided they respect those contracts.If the cache key is <tt>null</tt> then your component will not be cached at
+all. You can use this to your advantage to cache some things but not others.
+<section name="The Source Validity" style="background:none;padding:0;"/>The caching contracts use the Excalibur SourceValidity interface to determine
+whether a resource is valid or not. The validity can be a compound check that
+incorporates time since creation, parameter values, etc. As long as the sitemap
+can determine whether the cached resource is valid or not. More information is
+available on the
+<a href="http://excalibur.apache.org/sourceresolve/index.html">Apache Excalibur
+site</a>. Alternatively you can use the built in CacheValidity objects in the
+<tt>org.apache.cocoon.caching</tt> package and then use the
+<a href="http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/caching/CacheValidityToSourceValidity.html">CacheValidityToSourceValidity</a>
+adaptor object.The SourceValidity interface provides two <tt>isValid()</tt> methods, which
+are used to check the validity of a source. The first call is to the version
+without parameters, which the SourceValidity will return
+<tt>SourceValidity.VALID</tt>, <tt>SourceValidity.UNKNOWN</tt>, or
+<tt>SourceValidity.INVALID</tt>. If the first call responds with
+<tt>SourceValidity.UNKNOWN</tt>, then a new SourceValidity object is obtained
+from the CacheableProcessingComponent and that is passed into the
+<tt>isValid(SourceValidity)</tt> method. That can return the same set of
+responses. At this point, if the second comparison returns
+<tt>SourceValidity.UNKNOWN</tt> the action taken depends largely on the cache's
+algorithm. It may play conservative and invalidate the entry, or it may play
+loose and use it anyway. The general contract is that the new SourceValidity
+object is considered unusable. The contract is that a SourceValidity object will
+only be able to validate against another object of the same type. For example, a
+TimestampValidity object can validate against another TimestampValidity object
+but not a NOPValidity object.<p>The available SourceValidity objects provided by the Excalibur SourceResolver
+component are (in the order of commonality):</p><ul>
+<li><tt>NOPValidity</tt>--always valid</li>
+<li><tt>TimeStampValidity</tt>--valid until a newer timestamp is found
+(System.currentTimeMillis())</li>
+<li><tt>ExpiresValidity</tt>--valid until the expiration date is reached
+(System.currentTimeMillis() + time)</li>
+<li><tt>FileTimestampValidity</tt>--valid until the referenced file changes</li>
+<li><tt>AggregatedValidity</tt>--a compound validity object that is valid as
+long as all the encapsulated validity objects are valid</li>
+<li><tt>DeferredAggregatedValidity</tt>--a compound validity object that only
+gets validity objects if they are needed.</li>
+</ul><h3>NOPValidity</h3>Use the NOPValidity if you want to manually invalidate the cache entry for an
+item, or if you have an object that is created once and simply reused. It has
+limited use, but it is the easiest to set up. Just implement the
+<tt>getValidity()</tt> method like this:<pre>public SourceValidity getValidity()
+{
+ return NOPValidity.SHARED_INSTANCE;
+}
+</pre><h3>TimeStampValidity</h3>The TimeStampValidity object is most commonly used with blobs retrieved from
+the database, or some other information that only needs to be refreshed when a
+newer version exists. The TimeStampValidity will always return
+<tt>SourceValidity.UNKNOWN</tt> until it is compared against a new
+TimeStampValidity object so that it can compare the dates. You can use this
+validity object like this:<pre>SourceValidity validity = new TimeStampValidity(timestamp.getTime());
+
+public SourceValidity getValidity()
+{
+ return validity;
+}
+</pre><h3>ExpiresValidity</h3>The ExpiresValidity object is used for items you want to keep around for a
+while, but you know they will change within a certain amount of time. One
+example would be a clock snippet generator for your site. The clock is not going
+to change for the granularity that you are displaying. If the clock is
+displaying the hour and minute, then you could set the expiration time to
+System.currentTimeMillis() plus one minute. All calls during that minute would
+reuse the same information. While I doubt we would have a component that only
+generates the time of day, you get the general idea. You would set it up like
+this:<pre>SourceValidity validity = new ExpiresValidity(System.currentTimeMillis() + (60 * 1000));
+
+public SourceValidity getValidity()
+{
+ return validity;
+}
+</pre><h3>FileTimeStampValidity</h3>The FileTimeStampValidity is used most often by components that depend on an
+external file to produce its output. The most common examples would be your
+FileGenerator and the XSLTransformer components. The FileTimeStampValidity
+always checks the source file itself and uses the file system's timestamp to
+verify if the entry is still valid. You have three ways of setting it up:
+passing in the File reference, passing in the filename as a string, and passing
+in a combination of the File and the original timestamp. The
+FileTimeStampValidity is commonly used by the FileSource object. Below is an
+example of using the validity object:<pre>SourceValidity validity = new FileTimeStampValidity( sourceFile );
+
+public SourceValidity getValidity()
+{
+ return validity;
+}
+</pre><h3>AggregatedValidity</h3>The AggregatedValidity is the mechanism that you would usually use to combine
+any of the above validity types together and validate against all of them. For
+example, let's assume your Generator depends on a source file, but it also
+depends on some time dependant information that needs to be calculated every
+minute. We would set it up like this:<pre>AggregatedValidity validity = new AggregatedValidity();
+validity.add( fileSource.getValidity() );
+validity.add( new ExpiresValidity( System.currentTimeMillis() + (60 * 1000) ) );
+
+public SourceValidity getValidity()
+{
+ return validity;
+}
+</pre><h3>DefferedAggregatedValidity</h3>We usually don't use this validity object directly for Sitemap components,
+but it is referenced for the sake of completeness. It is used just like the
+AggregatedValidity object, only it adds an additional method to add
+DeferredValidity objects. The purpose is presumably to perform lazy
+initialization on some expensive validity objects so that the normal validity
+objects are evaluated first, and the other validity objects are created on
+demand. There are no stock DeferredValidity object implementations that I know
+of, so this is of little more than academic value for Cocoon components.</div></div>
+ </body></document>
\ No newline at end of file
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/675_1_1.xml
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/675_1_1.xml
------------------------------------------------------------------------------
svn:keywords = Date Revision Author HeadURL Id
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/675_1_1.xml
------------------------------------------------------------------------------
svn:mime-type = text/xml
Added: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/676_1_1.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/676_1_1.xml?rev=1329674&view=auto
==============================================================================
--- cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/676_1_1.xml (added)
+++ cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/676_1_1.xml Tue Apr 24 12:33:07 2012
@@ -0,0 +1,118 @@
+<?xml version="1.0" encoding="UTF-8"?><!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you 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.
+ --><document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/XDOC/2.0" xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd"><properties><title>Cocoon Core - Creating an Action</title><author email="cocoon-docs@apache.org">Apache Cocoon Documentation Team</author></properties><body>
+ <div id="contentBody"><div id="bodyText"><h1 class="docTitle">Creating an Action</h1><h1>Creating an Action</h1><p>Actions are unique in the world of Sitemap components. They don't implement
+the SitemapModelComponent and they merely exist to perform processing. For most
+business level processing, flowscript usually works better. However there are
+some systemic things we can implement using actions quite nicely. Actions are
+also unique in the sense that they do not need to be pooled. There is nothing in
+the contract that requires you to call multiple methods or do things in a
+certain order. Now a ThreadSafe component has its own challenges to ensure that
+the action is not a choke-point. Things to look out for are the use of
+<tt>synchronized</tt> when it is not necessary or trying to do too much in the
+action. Actions can be chained so keep things simple.</p><p>Actions have only one method to worry about. The sitemap invokes the method
+supplying several pieces of information and expects the return result of a
+<tt>java.util.Map</tt>. There are three outcomes from processing an action: the
+action succeeds and returns a java.util.Map, the action fails and return
+<tt>null</tt>, or the action throws an Exception. In the sitemap, an Action is
+invoked like this:</p><pre><map:act type="my-action" src="foo">
+ <map:generate src="{actionval}.xml"/>
+ <map:serialize/>
+</map:act>
+</pre><p>The sitemap only executes the elements internal to the <tt>map:act</tt>
+element when the Action returns a Map. If the Action returns null, that snippet
+is skipped. Using this to your knowledge you can provide confirmation pages that
+only show up when everything is processed successfully, otherwise we fall
+through to the remainder of the sitemap. Obviously we don't want to throw an
+exception if we can help it.</p><section name="What the Sitemap Provides" style="background:none;padding:0;"/><p>The sitemap provides the following elements:</p><ul>
+<li>Redirector--to perform redirects within the Action based on your logic.</li>
+<li>SourceResolver--to find resources.</li>
+<li>Object Model--to gain access to the request, context, and session objects.
+</li>
+<li>Source--the string defined in the "src" attribute in the Sitemap.</li>
+<li>Parameters--the parameters defined in the Sitemap at runtime.</li>
+</ul>Most of these items were covered in the
+<a href="673_1_1.html">SitemapModelComponent Contracts</a> documentation. The only
+item not covered so far is the Redirector. The
+<a href="http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/environment/Redirector.html">org.apache.cocoon.environment.Redirector</a>
+provides an interface to send a redirect so tha the browser requests a new
+document and we stop processing this one.<div class="fixme"><div><strong>Fixme: </strong>We need more information on when to call which method on the
+Redirector</div></div><section name="Creating the Action" style="background:none;padding:0;"/>It's not too hard to create an Action, but it can be difficult to keep track
+of what you are expecting the Sitemap to give you and what you give the Sitemap.
+As long as the purpose for your action is small and focused we can keep
+everything straight. What we are going to do here is create a "theming" action.
+The responsibility of the action is to select the stylesheet for the theme, but
+if the source is "xml" then we don't apply a stylesheet at all. It's actually
+not too difficult to perform. First let's set up our Sitemap:<pre><map:choose pattern="**.xhtml"
+ <map:generate src="{1}.xml"/>
+ <map:act type="theme">
+ <map:transform src="{theme}2xhtml.xsl"/>
+ </map:act>
+ <map:serialize/>
+</map:choose/>
+</pre>The plan is to use a parameter passed in to determine the theme. That means
+we aren't going to need the Source or SourceResolver parameters to perform our
+processing. We will need to extract the request parameter "theme" and interpret
+it. If "theme" has the value "xml" we don't do any transformations. If "theme"
+doesn't exist, we will provide a default value. And lastly, we will copy the
+request parameter "theme" to the returned Map so it is accessible inside.First the boiler plate code:<pre>import java.util.Map;
+import java.util.HashMap;
+import org.apache.avalon.framework.parameters.Parameters;
+import org.apache.avalon.framework.thread.ThreadSafe;
+import org.apache.excalibur.source.SourceResolver;
+import org.apache.cocoon.environment.ObjectModelHelper;
+import org.apache.cocoon.environment.Redirector;
+import org.apache.cocoon.environment.Request;
+import org.apache.cocoon.acting.Action;
+
+public class ThemeAction implements Action, ThreadSafe
+{
+ private static final DEFAULT_THEME = "default";
+
+ public Map act( Redirector redirector, SourceResolver resolver, Map objectModel, String source, Parameters params )
+ throws Exception
+ {
+ // .... the contents will be called out specifically below.
+ }
+}
+</pre>Now we can concentrate on the method itself. First things first, we need to
+get the "theme" request parameter. We do this by accessing the Request object
+from the object model:<pre>Request request = ObjectModelHelper.getRequest( objectModel );
+String theme = request.getParameter("theme");
+</pre><p>Ok, so we have the theme from the request object. Now lets check if it is
+empty and provide a default value if it is empty..</p><pre>if ( null == theme || theme.length() == 0 )
+{
+ theme = DEFAULT_THEME;
+}
+</pre><p>Next, let's check to see if the theme is the "xml" theme. We'll do it in a
+way that does not matter what case the "xml" value is. We return <tt>null</tt>
+in this case so that the transformer in the sitemap snippet above does not get
+added to the pipeline.</p><pre>if ( "xml".equalsIgnoreCase(theme.trim()) )
+{
+ return null;
+}
+</pre><p>Now we can assume that the value we have in the parameter "theme" is the name
+of a valid theme. We aren't going to do validation here, that's something you
+can have if you have inclination.</p><pre>Map returnValues = new HashMap();
+returnValues.put("theme", theme);
+
+return returnValues;
+</pre><p>That's it! We're done. We have an action that does not have to be pooled,
+selects a theme, provides a default, and does not apply formatting if the theme
+is "xml".</p></div></div>
+ </body></document>
\ No newline at end of file
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/676_1_1.xml
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/676_1_1.xml
------------------------------------------------------------------------------
svn:keywords = Date Revision Author HeadURL Id
Propchange: cocoon/trunk/site/cocoon-core-site/core/2.2/src/site/xdoc/676_1_1.xml
------------------------------------------------------------------------------
svn:mime-type = text/xml