forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juan Jose Pablos <>
Subject Re: Directory structure in 0.6 (Re: cvs commit: ...)
Date Tue, 22 Jul 2003 15:17:45 GMT

> And if the resource exists but I still want to transform it?
> And if I don't want to crawl all the source files?
> And if I *cannot* crawl them?
> Listen, this has come up a lot of times, and *was* in the Cocoon 
> pipeline, if not already there, and I proposed this several months ago.
> Not only it seems that you are not looking in the archives, but that you 
> are also not reading my mails with references I have dug up for you.

I am trying to find the best way than forrest can make out of a 
HTTP_REQUEST, I took that line from forrest.xmap, and I think that it is 
a good choice to have it.

I have not got any case where I do a pdf-pdf or png-png tranformation, I 
am not sure if many people use forrest for that (where is the code anyway?)

I am happy with any solution that keep things clean, like having only 
one content directory.

If you have source docs that you do not want to be touch/can not by 
forrest, why do you put it in the first place?

If it is only because you need a reference on the menu (ie <javadocs 
href="api/">) Maybe we need to create just an element similar to virtual 

> "
> Mind me, we still add a **.* matcher at the end of the
> content-handling pipeline, so that content/** can still contain anything 
> (ie cocoon can process it but in this case can also decide to just pass 
> along).
> But as you know in this way I cannot easily cater for the special case
> in which I want to explicitly have something as-is...
> "
> Your proposal does not work in case you cannot use the extension to 
> decide if giving the resource raw or not, and in the case in which these 
> sources are non-traversable.

Fine then.


View raw message