forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [SUMMARY] Cleaning Forrest source directory madness
Date Tue, 22 Jul 2003 12:28:33 GMT

Dave Brondsema wrote, On 22/07/2003 13.59:

> Quoting Nicola Ken Barozzi <>:
>>We would have use definable (KISS)
> good!
>>files to process-dir (1)
>>files not to process-dir (2)
>>What can [files to process (1)] contain?
>>- *.xml   (documentdtd, faq, changes, todo, status, etc)
>>- *.html  (html4, to be tidied)
>>- *.xhtml (xhtml1, xhtml2-dev)
>>- *.wiki
>>- *.png,gif,etc
> What do you mean by "process"?  Link-following and pipelining?

Basically yes.

> Are these two
> seperable (i.e., can forrest follow links from a raw .html)? 


Cocoon follows the links it gathers from the xml pipeline.

> How do png and gif
> files get processed?

Served as is usually.
But for a WAP skin, they can be resized on the fly.

>>The default content dirs 1,2 would be:
>>  documentation/
>>    content/*.xml (1)
>>    content/images/*.png (1)
>>    content/raw/foo.html (2)
>>The only special dir that will remain is "raw", and it seems that there 
>>is a real-life use case for it.
> What is this use case?  The only thing I can think of is that ihtml/ehtml (i
> forget which) files are now named .html (please point me to the discussion of
> this if I am mistaken) and so the raw/ directory is necessary to distinguish
> between a raw presentation of the html file and skinning the html file.  In this
> case, if only one type of presentation of html files is desired, only one
> directory is necessary (an xmap file may have to be changed if the desired
> presentation is not the default).
> If indeed the only use case is presentation of .html as both raw and skinned
> pages, I think this is so unlikely that by default it should not be handled.  If
> for some reason, someone needs this functionality, we can have an FAQ which
> explains how to modify their xmap files to use a raw/ directory.

Well, the "raw" dir is not something that should generally be used.
And in fact I have seen that more than 99% of the pages can go in 
content. And now, with the -pass the namespace along- rule, it should 
even be less.

But cases arise. They have already arised, and we should not forget them.

And one example that is not solved by the content dir is that of pages 
that cannot be traversed but that are linked. Cocoon would not copy them 

What we could do instead, is to not include the raw directory in the 
default fresh-site, but if the user creates it, it's used.

This should make it nicer for both cases, no?

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

View raw message