[prev in list] [next in list] [prev in thread] [next in thread]
List: xml-cocoon-cvs
Subject: cvs commit: xml-cocoon2/xdocs caching.xml
From: cziegeler () apache ! org
Date: 2001-06-26 7:24:24
[Download RAW message or body]
cziegeler 01/06/26 00:24:23
Modified: xdocs caching.xml
Log:
Updated doc
Revision Changes Path
1.6 +56 -7 xml-cocoon2/xdocs/caching.xml
Index: caching.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/xdocs/caching.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- caching.xml 2001/06/22 09:13:23 1.5
+++ caching.xml 2001/06/26 07:24:18 1.6
@@ -58,7 +58,7 @@
<p>When a response is cached all validity objects are stored \
together with
the cached response in the cache. Actually the \
<code>CachedEventObject</code>
is stored which encapsulates all this information.</p>
- <p>When a new response is generated and the key is generated, \
the caching + <p>When a new response is generated and the key is \
build, the caching
algorithm also collects all uptodate cache validity objects. \
So if the
cached response is found in the cache these validity objects \
are compared.
If they are valid (or equal) the cached response is used and \
feed into @@ -66,14 +66,49 @@
from the cache, the new response is generated and then stored \
together with the new validity objects in the cache.</p>
<s3 title="Examples">
- <p>Guess what! Yes, forthcoming.</p>
+ <p>If you have the following pipeline:</p>
+ \
<p>Generator[type=file|src=a.xml]->Transformer[type="xslt"|src=a.xsl]->Serializer</p> \
+ <p>The file generator is cacheable and generates a key which hashesthe src + \
(or the filename) to build the key. The cache + validity \
object uses the last modification date of the xml file.</p> + <p>The xslt \
transformer is cacheable and generates a key which hashes + \
the filename to build the unique key. The cache validity object + \
uses the last modification date of the xml file.</p> + <p>Both keys are used to \
build a unique key for this pipeline, + the first time it \
is invoked its response is cached. The second time + this \
pipeline is called, the cached content is get from the cache. + \
If it is still valid, the cached content is directly feed into + \
the serializer.</p> + <p>Only part of the following pipeline is cached:</p>
+ \
<p>Generator[type=file|src=a.xml]->Transformer[type="xslt"|src=a.xsl]->Transformer[type=sql]->Transformer[type="xslt"|src=b.xsl]->Serializer</p>
+ <p>The file generator is cacheable and generates a key which hashesthe src
+ (or the filename) to build the key. The cache
+ validity object uses the last modification date of the \
xml file.</p> + <p>The xslt transformer is cacheable and generates a key which \
hashes + the filename to build the unique key. The cache \
validity object + uses the last modification date of the \
xml file.</p> + <p>The sql transformer is not cacheable, so the caching algorithm \
stops + at this point although the last transformer is cacheable.</p>
+ <p>So the cached response is absolutely the same as in the first example
+ and therefore the unique key build from the two keys \
(from the + generator and the first transformer) is the \
same as in the first example. + The only difference is when the cached \
response is used. It is not + feed into the serializer but \
into the sql transformer.</p> </s3>
</s2>
<s2 title="The XMLSerializer/XMLDeserializer">
- <p>Forthcoming. Believe me!</p>
-<p>The storing of the sax events is implemented by two more
-Avalon components the XMLSerializer and the XMLDeserializer.
-</p>
+ <p>The caching if the sax events is implemented by two Avalon components:
+ The XMLSerializer and the XMLDeserializer. The XMLSerializer \
gets + sax events and creates an object which is used by the \
XMLDeserializer + to recreate these sax events.</p>
+ <s3 title="org.apache.cocoon.components.sax.XMLByteStreamCompiler">
+ <p>The <code>XMLByteStreamCompiler</code>compiles sax events into a byte \
stream.</p> + </s3>
+ <s3 title="org.apache.cocoon.components.sax.XMLByteStreamInterpreter">
+ <p>The <code>XMLByteStreamInterpreter</code> is the counterpart of the
+ <code>XMLByteStreamCompiler</code>. It interprets the byte
+ stream and creates sax events.</p>
+ </s3>
</s2>
</s1>
<s1 title="Caching of stream pipelines">
@@ -81,7 +116,21 @@
</s1>
<s1 title="Configuration">
<p>Configuration is forthcoming</p>
- </s1>
+ <s2 title="The XMLSerializer/XMLDeserializer">
+ <p>The XMLSerializer and XMLDeserialzer are two Avalon components which
+ can be configured in the cocoon.xconf:</p>
+ <source>
+ <![CDATA[
+ <xml-serializer class="org.apache.cocoon.components.sax.XMLByteStreamCompiler"/>
+
+ <xml-deserializer \
class="org.apache.cocoon.components.sax.XMLByteStreamInterpreter"/> +
+ ]]>
+ </source>
+ <p>You must assure that the correct (or matching) deserializer is
+ configured for the serializer.</p>
+ </s2>
+ </s1>
<s1 title="Java APIs">
<p>Description of the interfaces is forthcoming</p>
</s1>
----------------------------------------------------------------------
In case of troubles, e-mail: webmaster@xml.apache.org
To unsubscribe, e-mail: cocoon-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-cvs-help@xml.apache.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic