forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Cleaning Forrest source directory madness
Date Thu, 12 Jun 2003 12:38:17 GMT

Jeff Turner wrote, On 12/06/2003 13.58:

> On Thu, Jun 12, 2003 at 09:55:58AM +0200, Nicola Ken Barozzi wrote:
>>I'm looking into using XHTML 2.0, and now it seems to me that the
>>current documentation/ directory layout is confusing at best. To reduce
>>confusion I was obliged to use the default layout of Forrest in all my
>>IIRC I had started with that layout in the beginning, with the following
>>  content        all stuff that has to be "digested" by Forrest
>>    xdocs          xml document-dtd files
>>    images         (added later) images that refer to the dir xdocs
>>    -other-
>>  resources      all stuff that has to be referenced as-is
>>    images         images that have a global use in all pages
>>    -other-
>>The idea with resources, was that they would be referencable as local to
>>the current (.) dir even if the were not.
>>So a resource that was in
>>  resources/images/image.gif
>>could be called from:
>>  http://site/image.gif
>>  http://site/images/image.gif
>>  http://site/any/path/and/then/image.gif
> Oh, didn't know that.  Always wondered why images weren't content ;)


Resources are content, only more "static"; that's how I see the name, 
probably it's my misunderstanding of the meaning.

> Makes sense though.
> But now that we have site.xml and indirect linking, how about this
> instead:
> <figure src="img:project-logo">
> Where 'img:project-logo' is valid anywhere, 
> In the JIRA docs, the site.xml file has an <images> section, and a 'img'
> module that looks in there, in the same way as 'ext' looks in
> <external-refs>.  Works fairly decently.

Not bad.

But the main reason why it was put there was to make it easy to put 
javascripts or skin images, so IIUC it's a different use-case...

>>That was the initial meaning of resource. Something to remain as-is that
>>was referencable anywhere, both conceptually and in the path.
> Well it's not a good idea to have it *literally* in the output path,
> because then you get one copy per directory, which is wasteful.

Yup, right. Link rewriting is needed.

> I've run out of time.. will parse the rest tomorrow.


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

View raw message