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="[email protected]">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="[email protected]">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="[email protected]">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="[email protected]">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="[email protected]">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="[email protected]">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="[email protected]">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="[email protected]">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="[email protected]">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="[email protected]">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="[email protected]">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="[email protected]">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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.