forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: In-place editing (Re: [RT] Forrest source directory layout and resolving)
Date Sat, 04 Oct 2003 21:54:24 GMT
Jeff Turner wrote:

> On Wed, Sep 24, 2003 at 11:30:10AM +0200, Nicola Ken Barozzi wrote:
>>We need to tackle the Forrest source directory layout and how to resolve 
>>additional source dirs.
> ....
>>2 no more source copying
> This is the one I'm personally interested in tackling right now.
> Actually I've prototyped much of this locally.  It works (XML can be
> edited in-place) but isn't complete yet.  I've placed my experiments
> online at:

Since I really want to get this thing done, I have looked at the above 
mentioned files, and I've seen that there is still a mixture of two 
places where the sources are defined:

  1 - an xml config file
  2 - the sources xmap

 From our last discussion we had seen that using a sources xmap could be 
the best course of action, as it gives the greatest flexibility and 
makes it possible for users to start understanding Cocoon.

But it also exposes us to possible problems in the future when we would 
want to change the sitemaps. In fact I have the feeling that part of the 
blame of our slow speed is due to splitted sitemaps and continuous 
calling of cocoon://, although I haven't yet tested it.

Hence, probably a definition of dirs and additional sources could also 
be done in the config file...

>>Why do we have to copy the sources?
> Because:
> 1) We let users define their site structure however they want, yet our
> sitemap expects a certain format. 
> 2) We allow projects to override Forrest files:
> 2.1) If I have src/documentation/skins/forrest-site/css/page.css, it
> overrides that from the Forrest skin.  This applies to *any* skin file.

Till no wit's easy...
> 2.2) Sitemaps can be overridden.  If my project has a
> src/documentation/conf/sitemap.xmap, I want it to be used instead of the
> default.
> Two options for solving this:
> 1) We keep the existing solution of physically copying and overwriting
> xmap files.
> 2) We apply the 'virtual filesystem' pattern, and mount dynamically
> chosen sitemaps:
> <map:mount uri-prefix="" src="cocoon://forrest.xmap" check-reload="yes" />


Hmmm... does it work? I thought mounts were done at startup. In any case 
the idea is very nice.

This makes me think even more that we need to have at least some config 
info in an external file, so that normal uses would have to go without 
touching the sitemaps.

> We have a bootstrap problem with sitemap.xmap itself, although looking in
> cocoon.xconf, I see it is located with 'context://sitemap.xmap', so
> perhaps there's room for abstracting the location.

As long as we keep sitemap.xmap containing only mounts, it should not be 
necessary to extend it... hmmm...

> 3) We rely on @tokens@ in breadcrumbs.js

This can be fixed as you say with a text generator and a 
search-and-replace on it.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message