forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Jones <>
Subject Re: file: implemented (Re: cvs commit: ...)
Date Wed, 11 Dec 2002 02:04:06 GMT
Nicola Ken Barozzi wrote:
> Jeff Turner wrote:
>> On Tue, Dec 10, 2002 at 11:56:20AM -0000, wrote:

>>>  Log:
>>>  Add special handling of links that start with 'file:'.
>>>  These links are:
>>>   1) Not passed on to Cocoon (see filterlinks.xsl)
>>>   2) The 'file:' prefix is stripped from the HTML (see 
>>> filterlinks-html.xsl)
>>>   3) All file: links encountered during crawling are recorded in a file,
>>>   'unprocessed-files.txt' (see filterlinks.xsl and linkutils.xsl)
>>>   4) After running Cocoon, copies all files listed in
>>>   unprocessed-files.txt to build/site/ manually.  This is achieved 
>>> with a custom
>>>   selector,

Jeffs commit looks great!  It would exactly solve a simple problem 
simply.  As linking in static files will be incredibly common, it would 
be best if it is as simple and transparent to do so as possible. I 
understood this approach immediately upon reading your description, and 
it makes sense.  It would easily let me include those pesky pdf files 
that don't need transformations.  My only minor concern is that you used 
a scheme name that may be commonly found in URI's, ("file"), so you 
might want to consider something less prone to conflicts.

I'm not as excited about Nicola's proposal:

> My proposed solution is to
> 1) make Cocoon use resource-exists to see if it has to process it or not
> 2) if it has to process it, use CAPs to understand how
> 3) have the possibility of "mounting" documents from outside, ie if I 
> mount the /my/javadocs to the javadocs: protocol, I link to 
> "javadocs:index.html" and it gets resolved to the correct path.

This is confusing.  I've been poring over Forrest for the last week, 
trying to get it to do what I want, and this still doesn't make much 
sense to me.  I've read cap.html and it seems mildly relevant, but 
pretty darn indirect compared to having the document author directly 
specify what they want done with files.  What would I do?  How would I 
specify that x.pdf is not to be processed nor have its links mangled, 
but y.pdf should be?  This proposal from a naive perspective seems 
overly complex for what it provides -- very cocoon-like :)  I can see a 
shadow of an idea forming there in which the user need not specify at 
all how to process these files, but cocoon would automatically know what 
to do with files.  But my guess is this will actually require complex 
configuration for each site that is not at all transparent to the user.

I'm psyched to check out Jeff's changes and see if it works!

My $0.02.  Thanks for the great work.


View raw message