forrest-dev mailing list archives

Den 26. sep. 2006 kl. 12.37 skrev Ross Gardler:
>> I can open http://localhost:8888/index.en.html and have my page in
>> English. The problem with this solution is that it does not work
>> nicely in a webapp environment (e.g. forrest run), because this
>> locale encoding does not communicate with the locale modules in
>> Cocoon (LocaleAction, LocaleMatcher, I18nTransformer). Thus, all
>> menus and tabs are/will most likely be in a different language. In
>> addition, it's location in the menu is lost.
>
> This brings me back to the idea of using the locationmap for locale
> matching rather than Cocoons components, which have their problems
> in our use case. Something like (be warned, I've not fully thought
> this through and do not have any i18n sites, I'm not at all sure
> this will work in the real world):
>
> <match pattern="**.xml">
> <location src="{project:xdocs}/{1}.{2}.xml/>
> </location>
>
> <match pattern="**.*.xml">
> <select>
> <location src="{project:xdocs}/{1}.{2}.xml/>
> <location src="{project:xdocs}/{1}.{project:locale.default}.xml/>
> </select>
> </location>
This looses completely the concept of content negotiation, which is
exactly what the Cocoon modules provide. And this is really the core
of the problem: when running in a webapp environment, you want
negotiation, and ways to override the negotiated result, whereas in a
static build you don't want negotiation at all, just all files
generated to the requested output format(s).
Using the locationmap is fine, but not until content negotiation is
working.
I must admit I never tried the CLI during my development of the
language override menu, since my own usecase is solely 'forrest run'.
But we do need to generate a static version of our site as well, thus
this is also important to us.
>> The problem with static builds is a known one in that you can't
>> build all locales in the same run.
>
> Yes, but if we have an url with foo.html?locale=en then no static
> site build will work due to the way Cocoon encodes the url
> parameters in the filename. Unless you have found away this.
No. Now that I finally tried a static build, I have found lots of
errors durng the build, all of them belonging to two types:
X [0] wordsdoc/search/
index.html BROKEN:
org.apache.cocoon.environment.commandline.CommandLineRequest.getLocales(
) method not yet implemented!
X [0] /doc/ling/corpus-conversion-
tech.html BROKEN: dispatcherError: 500 - Internal server error
The contract "siteinfo-meta-navigation" has thrown thrown an
exception by resolving raw data from "cocoon://doc/ling/corpus-
conversion-tech.navigation.xml".
dispatcherErrorStack:
org.apache.excalibur.source.SourceNotFoundException: Exception during
processing of cocoon://doc/ling/corpus-conversion-tech.navigation.xml
The first error is clear enough - no direct support for locales in
the CLI.
The other one is harder - I already saw this error when running
forrest run, but I could not debug it. It seems to be a problem with
HTML source files only, and it is NOT related to dispatcher, despite
the text in the error message. It originates somewhere in the
**book.xml processing, breaking down in a sitemap match for no
appearent reason. More on this later.
>>> The global language default should be set in a config file.
>> Agree, I just don't know how to do it.
>
> It depends if you want to make your work compatible with 0.7
> version of Forrest. If you do then see [1], but for an easier way
> in 0.8 see [2]
0.8 is fine with us.
> Note both of these are issues to document this process, so ask
> questions if you don't understand.
Ok, I will.
> Ross
>
> [1] http://issues.apache.org/jira/browse/FOR-777
> [2] http://issues.apache.org/jira/browse/FOR-588
Sjur