Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <425826FB.4040507@apache.org>
Date: Sat, 09 Apr 2005 21:03:23 +0200
From: Sylvain Wallez <sylvain@apache.org>
Organization: Anyware Technologies
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Manually specifying a mounted sub sitemap's context
References: 
 <OF2127453A.AFCAF820-ONC1256FDE.006334D8-C1256FDE.0065D2FA@kuhnle.net>
In-Reply-To: 
 <OF2127453A.AFCAF820-ONC1256FDE.006334D8-C1256FDE.0065D2FA@kuhnle.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jochen Kuhnle wrote:

>Hi Sylvain,
>
>I agree that generated sitemaps are a somewhat more sophisticated use of 
>Cocoon. However, I think it is a nice feature to have. My main reason for 
>this is that I want to hide the nuts and bolts of sitemaps from site 
>maintainers and just want to give them a limited subset (or high-level XML 
>description) for the one specific site that is easy to understand and 
>maintain. So why not pre-generate it? So no-one ever forgets to do it!
>

Hmm... same use case as Gianugo. Is it possible for these files to be 
changed directly on the live site, or is this part of some kind of 
deployment operation?

>I found that it is quite efficient to generate the sitemap dynamically. 
>Since the sitemap-pipeline is created by a developer who knows more about 
>this stuff (including caching) than a maintainer, I think we can assume it 
>will be cacheable. Of course optimum support here would be to have the 
>map:mount code write "DANGER! Your sitemap pipeline is not cacheable" to 
>the log, but I don't think this is necessary.
>
>In addition, I can think of use cases where specifiable contexts might 
>come in handy even for "normal" sitemaps. One is that you maybe want to 
>differentiate access rights to sitemaps from access rights to content. 
>With a specifiable context, you could move all sitemaps into a special 
>sitemap-directory (or tree), separate from the content, and still avoid 
>ugly directory traversal prefixes to content files (<map:generate 
>type="jx" src="../../../path/to/the/content/directory/page.jx"/>). You get 
>"nicer" sitemaps, and you just have to set file permissions on two 
>directories (the sitemap and the site directory) instead of each and every 
>file.
>  
>

What you need here is a global variable that can be used as a prefix, 
thus writing <map:generate src="{global:base}/page.jx"/>

And if you find it too verbose, what you need is the sitemap to be able 
to define it's own context (i.e. <map:sitemap 
context="../../../path/to/the/content/directory">, see my previous post) 
and not have this context be defined externally.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director