P� 16. feb. 2005 kl. 12.56 skrev Thorsten Scherler:
El mi�, 16-02-2005 a las 11:03, Sjur Moshagen escribi�:
P� 14. feb. 2005 kl. 13.21 skrev Sjur Moshagen:
<map:parameter name="encoding" value="UTF-8"/>
but my UTF-8 wiki document is still read as Latin-1.
Is this a Forrest bug? A Chaperon Bug? A Cocoon bug? Am I missing something?
No response so far - does it mean that noone has this problem, or that noone has tried using the jspwiki input format with UTF-8 encoding?
Sjur
Not having the problem because never tried your use-case. Sorry for not being a bigger help.
...but having a quick look on the plugin raises the question whether you added <map:parameter name="encoding" value="UTF-8"/> as well to chaperon/sitemap.xmap?
Thanks for the tip. It didn't help, though.
I have now added the encoding parameter at the following locations:
$FORREST_HOME/plugins/wiki/input.xmap $FORREST_HOME/plugins/wiki/resources/chaperon/sitemap.xmap
The second of these is not used by Forrest, it is there because this directory is a copy of the Cocoon block.
Another variable in the bug hunting is whether it should be:
<map:parameter name="encoding" value="UTF-8"/> or <parameter name="encoding" value="UTF-8"/>
In the xmap files you need the namespace.
All other parameters in the mentioned files are without a namespace, but the documentation on the Chaperon site has a namespace. I have tried both with and without, to no avail.
Did you do "ant local-deploy" from within the plugin directory? This will deploy your changes to the running instance of Forrest.
If/when we are able to solve the problem, it seems to me that there should be a central configuration option (in forrest.properties) for the encoding of text file sources (*.jspwiki, *.txt, whatever is supported by forrest and its plugins), probably in a fashion similar to validation: one option for all text file types, and specific options to override the encoding of each type. As it is now, I am editing the Forrest sources to get what I want, which is not desirable in the long run.
Configuration of plugins is not possible yet, we have discussed various solutions over on the dev list, but none have been implemented yet. One thing is sure is that it should *not* be central. The whole idea of plugins is to decentralise. Furthermore, it doesn't really make sense to configure the plugin across the board since there may be multiple files each with different encodings.
Ross
