forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: file: implemented (Re: cvs commit: ...)
Date Tue, 10 Dec 2002 23:32:01 GMT

Jeff Turner wrote:
> On Tue, Dec 10, 2002 at 11:56:20AM -0000, wrote:
>>jefft       2002/12/10 03:56:20
>>  Modified:    .        build.xml status.xml
>>               src/resources/conf sitemap.xmap
>>               src/resources/forrest-shbat
>>               src/resources/fresh-site/src/documentation/content/xdocs
>>                        sample.xml
>>               src/resources/library/xslt filterlinks.xsl
>>  Added:       src/resources/forrest-shbat/tasks/org/apache/forrest
>>               src/resources/fresh-site/src/documentation/content hello.pdf
>>               src/resources/library/xslt filterlinks-html.xsl
>>                        linkutils.xsl
>>  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,
> Btw, the seed webapp includes an example of this.  The file
> src/documentation/content/hello.pdf is linked to in samples.xml, with
> <link href="file:hello.pdf">.
> The implementation is pretty ugly.  I found that appending to an external
> file in XSLT is a royal PITA.  It currently works with a Xalan
> <redirect:write> extension.  While XSLT 2.0 (Saxon) implements an
> equivalent <xsl:redirect-document>, it can't append to an existing file.
> I'm currently trying to write a Transformer that records 'file:' links to
> a WriteableSource, to replace all this hacky XSLT.

I think you jumped a bit too quickly on this, I'm -1 on it.

It really looks like a big hack to get round an issue we still have to 
finish discussing. I really don't like it, and would have preferred you 
wait a bit more before committing it.

Sorry if I'm a bit strong on it, but it creates more confusion and 

If we make links not be traversed in the definition, we are opening wide 
a door to abuse and failing of link checking.

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.

We mus talso remember that our goal is also not to copy anything but to 
have it processed by Cocoon in a "natural" manner.

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

View raw message