cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From da...@cocoon.zones.apache.org
Subject [DAISY] Updated: Cocoon 2.2 Sitemap internals
Date Thu, 06 Oct 2005 08:11:20 GMT
A document has been updated:

http://cocoon.zones.apache.org/daisy/documentation/732.html

Document ID: 732
Branch: main
Language: default
Name: Cocoon 2.2 Sitemap internals (unchanged)
Document Type: Document (unchanged)
Updated on: 10/6/05 8:11:00 AM
Updated by: Helma van der Linden

A new version has been created, state: publish

Parts
=====
Content
-------
This part has been updated.
Mime type: text/xml (unchanged)
File name:  (unchanged)
Size: 3234 bytes (previous version: 3041 bytes)
Content diff:
    <html>
    <body>
    
--- <p class="note">This information pertains to Cocoon 2.2!</p>
+++ <p class="fixme">To be done: <br/>
+++ - better images<br/>
+++ - links to apidocs of classes mentioned</p>
    
--- <p class="fixme">To be done: better images</p>
--- 
    <h1>Sitemap processing</h1>
    
    <p>Sitemap processing is done in three phases:</p>
(7 equal lines skipped)
    <h2>Phase 1: Build the sitemap tree</h2>
    
    <p>In Cocoon 2.2 the sitemap is internally represented by a tree that contains a
--- node for each matcher, generator, transformer, serializer and other modules used
--- in the sitemap. This process is executed each time the sitemap is changed and
--- needs to be reloaded.<br/>
+++ node for each matcher, generator, transformer, serializer and other components
+++ used in the sitemap. This process is executed at Cocoon startup and each time
+++ the sitemap is changed and needs to be reloaded.<br/>
    The actual process is done by the TreeProcessor. It builds an sitemap object
    tree and creates a ServiceManager. This is done for each sitemap and subsitemap.
    </p>
(3 equal lines skipped)
    
    <h2>Phase 2: Generate the pipeline</h2>
    
--- <p>When a request comes in, the tree is executed. This means that each matcher
--- is called with a request, until a matcher returns true. From that point the
--- underlying subtree is executed. All actions and selectors are resolved against
--- the current request. This means in effect that the subtree will revert to a
--- single path through the tree with only a generator, transformers and a
--- serializer as components.</p>
+++ <p>When a request comes in, the tree is executed. This means that each node is
+++ evaluated with the request. When a node evaluates to true, the underlying
+++ subtree is executed. Actions and selectors are resolved against the current
+++ request. This results in a single path through the tree with only a generator,
+++ transformers and a serializer as components.</p>
    
    <h2>Phase 3: Executing the pipeline</h2>
    
(9 equal lines skipped)
    reload the sitemap. The reloading is executed when a new request comes in. At
    that point, the current sitemap tree is marked for deletion. All the previous
    requests are still handled by the old version of the sitemap and a counter
--- counts down the requests until all requests are handled. Then the old version of
--- the sitemap is actually disposed.<br/>
+++ counts down the requests until all requests are handled. When the counter hits
+++ zero the old version of the sitemap is actually disposed.<br/>
    In the meantime a new tree is built and a new version of the ServiceManager is
--- setup. During the build process, all requests (i.e. the request that triggered
+++ set up. During the build process, all requests (i.e. the request that triggered
    the reload and all subsequent requests) are suspended until the build phase is
--- completed. Then all suspended requests are matched against the new version of
--- the tree.</p>
+++ completed. All suspended requests are then passed onto the new version of the
+++ tree. <br/>
+++ The image below shows the build process. The first request triggers phase 1, the
+++ build of the tree. All subsequent requests trigger phase 2.</p>
    
    <p><img src="daisy:735"/></p>
    
    <h2>Subsitemaps</h2>
    
    <p>Although subsitemaps basically follow the same process, they are not built
--- until they are needed.<br/>
--- When a request comes in and matches the URL of a mount node in the root sitemap,
--- it invokes a build of the subsitemap.</p>
+++ until they are needed. <br/>
+++ When a request matches the URL of a mount node in the root sitemap, it invokes a
+++ build of the subsitemap. The request is subsequently handled by the
+++ ServiceManager of the subsitemap.</p>
    
    <p><img src="daisy:736"/></p>
    
(10 equal lines skipped)


Fields
======
no changes

Links
=====
no changes

Custom Fields
=============
no changes

Collections
===========
no changes

Mime
View raw message