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 Sitemap internals
Date Thu, 06 Oct 2005 12:43:24 GMT
A document has been updated:

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

Document ID: 732
Branch: main
Language: default
Name: Cocoon Sitemap internals (unchanged)
Document Type: Document (unchanged)
Updated on: 10/6/05 12:43:15 PM
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: 10249 bytes (previous version: 10958 bytes)
Content diff:
(113 equal lines skipped)
    tree based on a file (e.g. sitemap.xmap) that is read in an Avalon configuration
    (this was chosen for its ease of use compared to raw DOM).</p>
    
+++ <p>The second section in the sitemaplanguage configuration, &lt;nodes&gt;,
+++ defines a ComponentSelector for ProcessingNodeBuilders. For each element 
+++ encountered in the sitemap source file, the corresponding node builder is
+++ fetched from this selector with the local name of the element as the selection
+++ hint, i.e. &lt;map:act&gt; will lead to selector.select("act").</p>
+++ 
+++ <p>The contents of each &lt;node&gt; element is the specific Avalon
+++ configuration of the corresponding ProcessingNodeBuilder and mostly define the
+++ allowed child statements.</p>
+++ 
    <h3>Roles, selectors and &lt;map:components&gt;</h3>
    
    <p>The &lt;map:components&gt; section of a sitemap is used to configure
a
(36 equal lines skipped)
    rootBuilder.buildNode method with the configuration tree created from the
    sitemap.</p>
    
--- <p>The FooNodeBuilder.buildNode method creates and returns a FooNode object
--- <br/>
--- &gt; and recursevly creates the child nodes of the object by creating and<br/>
--- &gt; executing the corresponding builder objects.<br/>
--- &gt; <br/>
--- &gt; Executing the tree<br/>
--- &gt; ------------------<br/>
--- &gt; <br/>
--- &gt; While (recursevly) executing the invoke(environment, context) method for
--- <br/>
--- &gt; the node objects in the tree a Pipeline object is constructed that is
--- <br/>
--- &gt; stored in the context object (other things happens as well). When a <br/>
--- &gt; SerializeNode is invoked, the current Pipeline is proccesed and the <br/>
--- &gt; output is stored in the environment.<br/>
--- &gt;</p>
+++ <p>Now a sitemap is not a tree, but a graph because of resources and views that
+++ can be called from any point in the sitemap. To handle this, building the
+++ processing tree follows two phases:</p>
    
--- <p>This ComponentsSelector handles the &lt;map:components&gt; syntax ("src"
and
--- <br/>
--- not "class", etc), and holds the "default" attribute, view labels and <br/>
--- mime types for each hint (these are not know by the components themselves).</p>
+++ <ul>
+++ <li>the whole node tree is built, and nodes that other nodes can link (or jump)
+++ to are registered in the common TreeBuilder by their respective node builders
+++ (see TreeBuilder.registerNode()).</li>
+++ <li>then those node builders that implement LinkedProcessingNodeBuilder are
+++ asked link their node, which they do by fetching the appropriate node registered
+++ in the first phase.</li>
+++ </ul>
    
--- <p>Building the processing tree<br/>
--- ----------------------------</p>
+++ <p>We then obtain an evaluation tree (in reality a graph) that is ready for use.
+++ All build-time related components are then released.</p>
    
--- <p>The second section in a language configuration, &lt;nodes&gt;, defines
a
--- <br/>
--- ComponentSelector for ProcessingNodeBuilders. For each element <br/>
--- encountered in the sitemap source file, the corresponding node builder <br/>
--- is fetched from this selector with the local name of the element as the <br/>
--- selection hint, i.e. &lt;map:act&gt; will lead to selector.select("act").</p>
+++ <p>It is to be noted also, that a ProcessingNode is considered as a "non-managed
+++ component": with the help of the LifecycleHelper class, the TreeBuilder honours
+++ any of the Avalon lifecycle interfaces that a node implements. This is required
+++ as many nodes require access to the component selectors defined by
+++ &lt;map:components&gt;. Disposable nodes are collected in a list that the
+++ TreeProcessor traverses when needed (sitemap change or system disposal).</p>
    
--- <p>The contents of each &lt;node&gt; element is the specific Avalon
--- configuration <br/>
--- of the corresponding ProcessingNodeBuilder and mostly define the allowed <br/>
--- child statements.</p>
+++ <p>Great care has been taken to cleanly separate build-time and run-time code
+++ and data, to ensure the smallest memory occupation and the fastest possible
+++ execution. This resulted in this intepreted engine to be a bit faster at runtime
+++ than the compiled one (build time is more than 20 times faster).</p>
    
--- <p>Now a sitemap is not a tree, but a graph because of resources and views
--- <br/>
--- that can be called from any point in the sitemap. To handle this, <br/>
--- building the processing tree follows two phases:<br/>
--- - the whole node tree is built, and nodes that other nodes can link (or <br/>
--- jump) to are registered in the common TreeBuilder by their respective <br/>
--- node builders (see TreeBuilder.registerNode()).<br/>
--- - then then those node builders that implement <br/>
--- LikedProcessingNodeBuilder are asked link their node, which they do by <br/>
--- fetching the appropriate node registered in the first phase.</p>
+++ <h2>Phase 2: Executing the tree</h2>
    
--- <p>We then obtain an evaluation tree (in reality a graph) that is ready for
--- <br/>
--- use. All build-time related components are then released.</p>
+++ <p>While (recursively) executing the invoke(environment, context) method for the
+++ node objects in the tree a Pipeline object is constructed that is stored in the
+++ context object (other things happens as well). When a SerializeNode is invoked,
+++ the current Pipeline is processed and the output is stored in the environment.
+++ </p>
    
--- <p>It is to be noted also, that a ProcessingNode is considered as a <br/>
--- "non-managed component": with the help of the LifecycleHelper class, the <br/>
--- TreeBuilder honours any of the Avalon lifecycle interfaces that a node <br/>
--- implements. This is required as many nodes require access to the <br/>
--- component selectors defined by &lt;map:components&gt;. Disposable nodes are
--- <br/>
--- collected in a list that the TreeProcessor traverses when needed <br/>
--- (sitemap change or system disposal).</p>
--- 
--- <p>Great care has been taken to cleanly separate build-time and run-time code
--- and data, to ensure the smallest memory occupation and the fastest possible
--- execution. This led this intepreted engine to be a bit faster at runtime than
--- the compiled one (build time is more than 20 times faster).</p>
--- 
    <h2>Phase 3: Create the pipeline</h2>
    
    <p>When a request has to be processed, the TreeProcessor calls invoke() on the
(16 equal lines skipped)


Fields
======
no changes

Links
=====
no changes

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

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

Mime
View raw message