forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@upaya.co.uk>
Subject Re: Multiple file output formats and views (skinned-source-translation-etc)
Date Sun, 09 May 2004 08:08:55 GMT
Nicola Ken Barozzi wrote:

>
> Usually Forrest works like this:
>
>  * file.sourceextension
>            |
>            V
>  * file.xdoc
>            |
>            V
>  * file.resultextension
>
> So I can have one of these:
>
>  file.xml
>  file.cwiki
>  file.txt
>
> any of them will be transformed in xdoc and can be rendered, for 
> example, in:
>
>  file.html
>  file.pdf
>
>                          - 0 -
>
> We have already seen though how this is not all that we need.
> Sometimes we need to have files as-is, so we have a raw-dir, that 
> contains file to be served as-is. This is not optimum though, as it 
> puts a special place for the source files.
>
> In alternative it has been said that in site.xml one could specify if 
> the file is to be served as-is or not, and this is much better.
>
> But then, another factor comes into play.
>
> Let's say that we include .java files in the ones that can be processed.
> The most obvious thing to do is to colorize the source code:
>
>  * file.java
>            |
>            V
>  * file.xdoc
>            |
>            V
>  * file.html (colorized source code)
>
> Or... maybe javadocs?
>
>  * file.java
>            |
>            V
>  * file.xdoc
>            |
>            V
>  * file.html (javadoc)
>
> Or... a translated version of the javadocs?
>
>  * file.java
>            |
>            V
>  * file.xdoc
>            |
>            V
>  * file.html (javadoc in french)
>
> Things become more complicated when I have the same format as the output:
>
>                          file.html
>                              |
>                              V
>                         (file.xdoc)
>            |           |           |          |
>            V           V           V          V
>
>         file.html  file.html  file.html  file.html
>         (skinned)  (as-is)     (docs)    (translated)
>
>
>
>                          - 0 -
>
> Ok, so I hope I've explained the problem. We have multiple outputs and 
> only one input.
>
> Cocoon has a very neat concept of this called "views". We could have a 
> default view and define the other ones as different views of the same 
> source.
>
>   index.html
>   index.html?cocoon-view=source
>   index.html?cocoon-view=docs
>   index.html?cocoon-view=translated&language=fr
>
> This is ok for live sites, but for static sites?
>
> It's easy to see that the default output is the one that skins the 
> file to make it published on the website.
>
> The question is: how do we make the urls of the other views? Should we 
> simply follow the Cocoon CLI convention on views to flatten the names 
> or use another scheme?
>
If you use the CLI to rewrite filenames, you need to have it rewrite 
links within pages too, which really slows things down. So if you can do 
it without using that CLI functionality, so much the better.

Of course, you could get the CLI to rewrite filenames and handle the 
link rewriting yourself, but then your links wouldn't work in the live 
site? (Unless you made a dynamic redirect from the rewritten view url to 
the actual view, e.g. index_source.html->index.html?cocoon-view=source).

I'm open to the CLI having a more sophisticated way of rewriting 
filenames. It has been asked for, but I just haven't been able to work 
out for myself how to do it. There are three options that come to mind 
immediately:
1) Ignore the request parameters
2) Just replace & and ?, etc: index.html_cocoon-view_source (but this is 
static server unfriendly and ugly)
3) Place the request param stuff before the extension: 
index.cocoon-view.source.html

Thoughts?

Regards, Upayavira



Mime
View raw message