forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [UPDATE] Forrest source directory layout and resolving
Date Thu, 09 Oct 2003 12:01:47 GMT
Jeff Turner wrote:

> On Wed, Oct 08, 2003 at 01:51:03PM +0200, Nicola Ken Barozzi wrote:
>>Jeff Turner wrote:
>>>On Tue, Oct 07, 2003 at 11:59:05AM +0200, Nicola Ken Barozzi wrote:
>>>>Here is an updated status on my proceedings about the source directory 
>>>>layout and resolving, divided by the objectives:
>>>>2 no more source copying
>>>To report on updates: I've been trying to fix up and commit the old xmaps
>>>that remove the necessity for copying.
>>>It's gradually occurred to me that perhaps we'll never be able to
>>>completely remove the need for copying.  The problems are quite large:
>>>- The src/documentation/{lib,classes} directory's contents need to be in
>>>  WEB-INF/lib/.  We could hack Jetty's classpath to include these, but
>>>  that's not a very nice solution
>>I was never aware that we were making this extension possible. Do we 
>>*really* need it?
> Yes, it's very useful.  You can put jimi.jar in src/documentation/lib/
> and everyone building the project will get images in their PDFs.  Custom
> sitemaps can use custom components not included with Forrest.

As for jimi, it's a the only case AFAIK of what we can do already but 
users need to install by hand.
Oh well... then it's linked to the custom sitemap stuff issue.

>>>- src/documentation/*.xmap sitemaps need to override their generic
>>>  equivalents, and I still don't know how we could do this.
>>IMHO we will have to break this if we want to remove copying.
> Can't, as this is the only way to customize Forrest.
>>Or at least make this be done *only* if there is something to override. 
> That's the only reason there would be xmap files in src/documentation.

So if there are we copy, in the other case we can also do without it.

>>In this case we will eliminate the need for copying for most, possibly
>>all with the sourcemap, uses.
> 'most' unfortunately isn't an option, unless we want to maintain both new
> and old systems.


>>>- Anything in resources/{images,stylesheets,grammars,schema} could
>>>  potentially be overridden by an identically named file in
>>>  src/documentation/resources/{...}.  This means that for large
>>>  proportions of our sitemap, we'll have to use actions to do an
>>>  if-then-else check.  This will have unhappy consequences to
>>>  readability and speed.
>>This should be eliminated by a well designed sourcemap, as these values 
>>can be cached.
> As you said in your last mail, cocoon:// is slow, and <map:act>'s all
> over the place is ugly.

Sourcemaps don't use cocoon protocol or acts. They map a virtual source 
request to a real source.

That is I ask the sourcemap to give me the resolved String containing 
the path to get a source. This way the sitemap has a clean virtual 
source space, so no acts ot cocoon protocols are needed.

The only thing that srcmap has to do is to ping the source at least once 
for existence, but that can be cached, and it gives back the string just 
with a hashtable lookup in the next request.

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

View raw message