cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Manually specifying a mounted sub sitemap's context
Date Sun, 10 Apr 2005 14:32:36 GMT
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! 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.

here is my rationale for the my everlasting -1 on a dynamic sitemap 
(this -1 is there since 2000, and I'm not changing it).

the sitemap is one of the key functionalities of cocoon, having it 
dynamic would allow people to avoid fighting for a functionality and 
work around it on their own.

if you feel you need dynamic sitemaps, is because the sitemap is not 
powerful enough for what you want to achieve. If that is the case *I* 
want to fix the sitemap, rather than allow you to branch off and patch 
it on your own.

Sure, it takes longer and sure, it might not be exactly what you wanted, 
but it will do the job, meet the requirements and make *everybody* advance.

Example: virtual pipeline components were introduced to solve some 
pipeline reusability issues, if we had dynamic sitemaps, people would 
have worked around that problem with a bunch of (unreusable for others!) 
XSLT.

So, if you think there is a functionality missing in the sitemap, 
propose a way to fix it, don't propose a way for you to route around it.

-- 
Stefano.


Mime
View raw message