forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject [RT] Forrest source directory layout and resolving
Date Wed, 24 Sep 2003 09:30:10 GMT

We need to tackle the Forrest source directory layout and how to resolve 
additional source dirs.

1 new and cleaner standard layout
2 no more source copying
3 definition of additional user resources

1 new standard layout

This was the last proposal that had consensus IIUC:

 From this thread I took the fiollowing stuff:

The default Cocoon doc space is:

    content -> model
      - files to process (1)
      - files not to process (2)
    resources -> controller
    skins -> view

So we would have use definable (KISS)

content-dir (1)
raw-dir (2)

The content dir is about all content, that Forrest *may* alter.
The raw dir is about content that Forrest may *not* alter in any way.

The content-dir can contain:

- *.xml   (documentdtd, faq, changes, todo, status, multischema, etc)
- *.html  (html4, to be tidied as is now ihtml)
- *.xhtml (xhtml1, xhtml2-dev)
- *.cwiki
- *.png,gif,etc
- *.txt

2 no more source copying
Why do we have to copy the sources?

Someone can help me in hashing out the things to be resolved to make 
this happen?

3 definition of additional user resources

This is what, IIRC, came out from a brief discussion between me and Jeff.

If we add a source.xmap part in the sitemap that only resolves the 
sources, the users can override it and specify additional source 
locations, that can be also off-disk or even directly from a VCS.

It would not break our system if we maintain the uri contracts in it 
stable, and makes it easy to start understanding how sitemaps work, as 
simple mappings are easy to hack on.

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

View raw message