forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: URI spaces: source, processing, result
Date Wed, 11 Dec 2002 16:15:01 GMT
On Wed, Dec 11, 2002 at 03:34:59PM +0100, Nicola Ken Barozzi wrote:
> Last commit of Jeff about the "link:" usage and my commit about 
> resource-exists everywhere are all tentatives to resolve an issue that 
> is still unfortunately open. Add to that topicmaps, linkmaps, and local 
> dir hierarchy, and we definately have an issue to solve about URI spaces.
> Now, IMHO these things are being difficult to resolve because we mix 
> problems together, so I'll try here to separate them in different sections.
>  SoC
> -----------------------
> SoC means that the user should not tell the system how it wants the 
> files to be processed.

Or rather, no assumptions about the processing tool should creep into the
source.  Before SoC and IoC, this was called "common sense" :)

> It just puts content on the disk and Forrest creates a site out of it.

<snip completely unrelated directory layout discussion>

<snip decent description of linkmap>

>  Source Mounting
> -----------------------

I can't see how this relates to the file: question, but anyway..

> We should be able to include external directories in our local contents.
> For example, if I have
>  ./src/documentation/**
> and
>  ./build/javadocs/**
> I may want to make Forrest work as if the javadocs were in
>  ./src/documentation/javadocs/**
> without having to actually move the files there.
> This is not only about files that must be served as-is, but also served 
> as if they were in the normal hierarchy (ie xdocs).
> This means that probably we should make our own sourceresolver or 
> filegenerator and have that keep a mounting config that can tell where 
> to get the files.
> Or maybe just a SourceMountTranslate action to be called before every 
> generation, that resolves the real source path, given the mount point.

Are you really suggesting that requests for Javadoc pages should go
through Cocoon?

That is completely crazy!  Cocoon's javadocs are 21mb.  Guess how long it
will take for the CLI to pointlessly filter them through Cocoon,
untransformed... just so we can say "everything goes through Cocoon".

But the problem is real: how do we integrate Javadocs into the URI space.

I'd say write out .htaccess files with mod_rewrite rules, and figure out
what the equivalent for Tomcat is.  Perhaps a separate servlet..
_anything_ but Cocoon ;P

> Thus linking to these external resources will be done exactly as if they 
> were in the normal dir space.
> Does this make sense?

Yes.  I see you've let in the door two schemes, 'javadoc:' and 'linkmap:'
(what I was calling 'site:'), so adding 'file:' or 'source:' to indicate
static content shouldn't cause any conceptual hiccups.


View raw message