cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [DAISY] Created: Sitemap FAQs
Date Thu, 22 Sep 2005 13:51:43 GMT
A new document has been created.

Document ID: 714
Branch: main
Language: default
Name: Sitemap FAQs
Document Type: Document
Created: 9/22/05 1:51:24 PM
Creator (owner): Helma van der Linden
State: publish


Mime type: text/xml
Size: 8440 bytes

<h2>What are the steps to pre-compile the sitemap and XSP's?</h2>

<li>Set the auto-reload to false in your sitemap.xmap as follows:</li>

<pre>&lt;parameter name="auto-reload" value="false"/&gt;

<li>Use "-Dbuild.precompile=true" in your build command line when you are
building your WAR file.</li>

<h2>I don't want to hand edit the sitemap. Are there any tools?</h2>

<p>Try <a href="">this</a> by Bruno Dumon.</p>

<h2>How do I create some content which isn't directly visible to everyone?</h2>

<p>Put the content in an internal pipeline...</p>

 &lt;map:pipeline internal-only="true"&gt;
   &lt;map:match pattern="int"&gt;
     &lt;map:generate src="docs/description.xml"/&gt;
     &lt;map:serialize type="xml"/&gt;
   &lt;map:match pattern="desc.html"&gt;
     &lt;map:generate src="cocoon:/int"/&gt;
     &lt;map:transform src="stylesheets/description2html.xsl"/&gt;
     &lt;map:serialize type="html"/&gt;

<h2>How can I concatenate two xml files?</h2>

 &lt;map:pipeline internal-only="true"&gt;
   &lt;map:match pattern="one"&gt;
     &lt;map:generate src="docs/one.xml"/&gt;
     &lt;map:serialize type="xml"/&gt;
   &lt;map:match pattern="two"&gt;
     &lt;map:generate src="docs/two.xml"/&gt;
     &lt;map:serialize type="xml"/&gt;
   &lt;map:match pattern="desc.html"&gt;
     &lt;map:aggregate element="newRootElement"&gt;
       &lt;map:part src="cocoon:/one" element="firstXMLfile"/&gt;
       &lt;map:part src="cocoon:/two" element="secondXMLfile"/&gt;
     &lt;map:transform src="stylesheets/merge2html.xsl"/&gt;
     &lt;map:serialize type="html"/&gt;

<p>Where the element attribute names are replaced with something more
meaningful! Note that the map:part element attributes can be left off, which
results in the two parts being placed one immediately after the other.</p>

<h2>I want to use the XXX matcher/serializer/selecter/etc but there's no
examples :(</h2>

<p>If you've checked the sample webapps which come with Cocoon, and you've
looked in the documentation, then check both the user and dev archives. If it
hasn't been resolved before <strong>first</strong> email the user group and,
after a <strong>reasonable</strong> (i.e. 1 or 2 days) length of time (remember
not everyone lives in your timezone) email the dev group.</p>

<p>Please don't cross-post to both the user and dev groups - very few people
like getting bombarded!</p>

<p>Oh, and once you do get it working - how about documenting it and
contributing it back to the group?</p>

<h2>I changed the sitemap, but my changes don't show in the browser. Do I need
to restart the servlet container?</h2>

<p>Cocoon lets you decide whether it needs to poll for sitemap changes (with its
associated performance penalty) or not. It also lets you decide whether the
re-compilation resulting from polling shoud happen in the background or in the

<p>If you look at the cocoon.xconf file, you'll notice this element:</p>

<pre>&lt;sitemap file="sitemap.xmap"

<p>Which means:</p>

<li>The <tt>check-reload</tt> attribute determines if the sitemap is reloaded
change. Set to "no", the sitemap is generated once at startup. Set to "yes", the
sitemap is regenerated if it changes.</li>
<li>The <tt>reload-method</tt> specifies the method for the regeneration:
<li><tt>asynchron</tt>: If the sitemap changes, the sitemap is regenerated
the next request in the background and the incoming request is served with the
old sitemap. All subsequent requests are served with the old sitemap until the
regeneration in the background has finished.</li>
<li><tt>synchron</tt>: If the sitemap changes, the sitemap is regenerated
at the
next request. When the regeneration is finished, the request (and all subsequent
ones) is served with the new sitemap.</li>

<p>For a development environment, set the reload-method to "synchron" and the
check-reload to "yes." For a production environment, set the reload-method to
"asynchron." For more safety, set the check-reload to "no."</p>

<p>In a nutshell: By default, reload is "asynchron" which means:</p>

<li>Change sitemap</li>
<li>Hit reload</li>
<li>Wait while CPU goes up to 100% and back down to 0%</li>
<li>Hit reload</li>
<li>Voila - new sitemap is used! :)</li>

<p>Hence: you don't need to restart the servlet container.</p>

<p>For sub-sitemaps, this issue is defined in the mounting element:</p>

<pre>&lt;map:mount uri-prefix="foo" src="file:///c:/foo/"

<p>With these settings Cocoon will react to any changes in the sub-sitemap,
without even hitting the reload button twice. :)</p>

<p>Moreover, it is a good idea to use sub-sitemaps because they reduce overall
compilation time. For example, changes to a single sub-sitemap won't require
recompilation for the the main sitemap or other sub-sitemaps. This practice
leads to greater degree of modularity.</p>

<h2>When I add an action to a pipeline Cocoon returns an error.</h2>

<p>Before the action was added to the pipeline it worked fine. After the change
Cocoon seems not to find the file specified in the variable that is returned by
the matcher.</p>

<pre>&lt;map:match pattern="*"&gt;
  &lt;map:act type="validate-session"&gt;
    &lt;map:generate type="serverpages" src="{../1}.xsp"/&gt;

<p>Please note in the above example the "<strong><tt>../1</tt></strong>".</p>

<p>Map objects returned from matchers, actions etc. are organised
<em>hierarchically</em>. Therefore they are not replaced by new ones but older
ones are still accessible through a path expression. Here "<tt>../1</tt>"
references key ("variable") "1" in the next to last Map.</p>

<h2>What is the syntax for absolute filesystem pathnames.</h2>

<p>In your sitemaps you may need to refer to some resource that is outside the
webapp context (e.g. UNIX /foo/bar/this.xsl e.g. Windows C:\foo\bar\this.xsl).
You need to use the file: convention.</p>

<li>UNIX ... <tt>file:///foo/bar/this.xsl</tt></li>
<li>Windows ... <tt>file:///C:/foo/bar/this.xsl</tt></li>

<p>See further explanation of <a href="daisy:580">file: URLs</a></p>

<h2>What's the difference between having two pipelines with one matcher each,
and one pipeline with two matchers?</h2>

<p>If there is no other difference in pipeline declarations, then none, really.
Note that pipelines can differ by:</p>

<li>visibility: internal-only="true" (not accessible for external requests) or
<li>error handling: using different &lt;handle-errors&gt;s.</li>
<li>cachability (since 2.1): some requests can use cached responses from caching
pipeline. Others, which should not be cached, can be handled by the non-caching
pipeline implementation.</li>
<li>logical grouping: logically-related components can be grouped into separate
pipelines to improve readability and ease administrative concerns.</li>
<li>ids: used to identify pipeline and other elements. See the "sitebuilder"
sitemap editor in scratchpad samples for an example.</li>

<h2>Where can I find more information about the sitemap?</h2>

<p>Learn more about advanced Sitemap features by downloading the free chapter,
<a href="{C3C05052-BE3B-4E06-A60A-13FB40AF58F6}">A
User's Look at the Cocoon architecture,</a> from Langham and Ziegeler's
<em>Cocoon: Building XML Applications</em> available at the New Riders web site.

<p>Check out a draft XML Schema
<a href="*checkout*/cocoon-2.1/src/documentation/xdocs/drafts/sitemap-2.1-draft.xsd?rev=HEAD&amp;content-type=text/plain">grammar
for the Cocoon sitemap</a>, and some
<a href="">external documentation</a> generated
from this Schema. A poster diagram of the sitemap structure is also available.


The document belongs to the following collections: legacydocs

View raw message