cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Lutz <>
Subject Re: Locale Bug in CForm ?
Date Thu, 11 Aug 2005 14:05:48 GMT
Leszek Gawron wrote:

> Thomas Lutz wrote:
>> Leszek Gawron wrote:
>>> Thomas Lutz wrote:
>>>> private Locale locale = Locale.getDefault();
>>>> It takes the default locale from the host, but shouldn't it take 
>>>> the locale set via the browser or the ? So the 
>>>> line should rather be something like:
>>>> private Locale locale = I18nUtils.findLocale(....); ?
>>> in your own cocoon webapp you can do:
>>> var form = new Form( "cocoon:/form-def/" + config.filterModelName );
>>> form.locale = determineLocale();
>>> and implement determineLocale() with any logic you like.
>>> For cocoon samples: we should probably make use of LocaleAction.
>> I tried to do this in javaflow (as I only use java as flow script 
>> language), that's not that easy. 
>> has no setter for it's 
>> member locale, and locale is private... so no chance of tweaking in ?
> I do not know how you do it in javaflow but here is how 
> HandleFormSubmitAction does it:
> Form form = formManager.createForm(source);
> Request request = ObjectModelHelper.getRequest(objectModel);
> FormHandler formHandler = null;
> if (formHandlerClassName != null) {
>     // TODO cache these classes
>     Class clazz = Class.forName(formHandlerClassName);
>     formHandler = (FormHandler)clazz.newInstance();
>     LifecycleHelper.setupComponent(formHandler, null, null, manager, 
> null);
>     form.setFormHandler(formHandler);
> }
> FormContext formContext = new FormContext(request, locale);
> boolean finished = form.process(formContext);
> request.setAttribute(formAttribute, form);
> you can pass locale via FormContext instance.

Ok, I figured out how it could be done in javaflow, but this would 
require a patch on

This class is the form interface for javaflow, as far as I understood 
from the samples. In its function the FormContext is used as 
in your example. It uses the private member locale, that is never set 
by  a constructor or a setter, so if I added them, I could set the forms 
locale from javaflow, too.

If a patch for this is welcome, I'll do my very best :-) and add it to 

>> What's the reason for Locale.getDefault() ? At least I would expect 
>> to behave forms like all other I18N components, and take the locale 
>> from the user agent, so dates and whatsoever get a proper formatting 
>> in the forms... or am I missing something ?
> I think this is a good choice that core cforms classes do not depend 
> on environment. Every user is free to choose the method to determine 
> locale. You could implement a scenario where locale is fetched from 
> user personal settings stored in database.
Well, I agree that every user or better developer should be free to 
choose his method of locale determination. But, on the other hand it 
seems very confusing to me, that cforms uses the hosts default locale, 
where all (ehm, all that I know :-)) other I18N components use the one 
specified by
This should be consistent, shouldn't it ?
So, imho cforms should use the locale "from LocaleAction", too, if 
someone wants another method of of locale determination, he still could 
implement it. It's just a matter of default unification| I think.

View raw message