You still need to be careful though, it sounds like the receiver of your form after submission isn't correctly handling the foreign locale. There are other places however that do handle it correctly (service events) and those places will probably break if you try and pass US specific number formatting to them when another locale is being used.
Regards
Scott
On 27/07/2010, at 10:34 AM, Ruth Hoffman wrote:
> Hi Adrian:
> This is exactly what I was looking for. I was going to try and track down
> what was happening and then try and do something to overcome the problem.
> That is, once I understood how it worked.
>
> Since Scott came up with a solution that works for me - no coding involved -
> yeah! - I'm using that.
>
> Thanks again.
> Regards,
> Ruth
>
> Adrian Crum wrote:
>> Based upon your description of what is being displayed, the conversion is
>> being done in Freemarker. When you use the expression:
>>
>> ${orderItem}
>>
>> Freemarker calls the GenericValue's toString method. GenericValue converts
>> its contents to a String internally - that's why you see a decimal point.
>>
>> When you use the expression:
>>
>> ${orderItem.unitPrice}
>>
>> Freemarker calls GenericValue.get - which will return a BigDecimal.
>> Freemarker will convert the BigDecimal to a String using the current locale
>> - which has been set to the user's locale. If the user's locale is in
>> France, you will see commas.
>>
>> That's why I suggested using a Freemarker built-in or whatever to specify a
>> locale just for that expression and not the whole screen.
>>
>> -Adrian
>>
>> On 7/26/2010 2:51 PM, Ruth Hoffman wrote:
>>> Now that I have your attention:
>>>
>>> So what is really happening is that the value, if printed out without
>>> any formatting at all is displayed correctly. For example, lets say
>>> orderItems is a list with a single orderItem GenericValue where
>>> orderItem.unitPrice = 10.950 (that is the value as seen in the database).
>>>
>>> Then, in orderReview.ftl (9.04) and as passed to this template by a
>>> Groovy script, if I print this out like this:
>>> ${orderItem}
>>>
>>> The GenericValue returned is a display something like:
>>> BigDecimal:10.950. To me, this makes sense.
>>> -------
>>> OK, so far?
>>> Now, if I do this:
>>> ${orderItem.unitPrice}
>>> I'll get a value returned that looks something like: 10,95
>>>
>>> So, without even using the currency conversion, I'm stuck. Somewhere,
>>> somehow, OFBiz knows that "unitPrice" is a BigDecimal and is not
>>> converting it correctly when the locale is not English. "10.950" is not
>>> the same as "10,95". Now that I'm thinking about it, I don't think this
>>> is a currency issue at all. I think it is a BigDecimal conversion problem.
>>>
>>> So, back to my original question: Where is this done?
>>>
>>> Regards,
>>> Ruth
>>> Scott Gray wrote:
>>>> That's your question :-)
>>>>
>>>> Ruth's question was about how the decimal point became a comma.
>>>>
>>>> If I were dealing with the problem, I would worry less about what the
>>>> string looks like in any given locale and instead be worrying about
>>>> why the locale specific input parameter isn't being correctly
>>>> converted back to a number. I guess that's what you are alluding to as
>>>> well Adrian.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 27/07/2010, at 9:08 AM, Adrian Crum wrote:
>>>>
>>>>> The question is: What happens when the user clicks the submit button?
>>>>> The request parameters are sent with numbers formatted according to
>>>>> the locale specified in the transform, and the framework will be
>>>>> expecting them to be formatted according to the user's locale.
>>>>>
>>>>> It's an interesting problem. Changing the conversion code is not the
>>>>> solution however.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 7/26/2010 2:03 PM, Scott Gray wrote:
>>>>>> In freemarker we typically use the OfbizCurrencyTransform which
>>>>>> takes a Number and converts it to a locale specific string
>>>>>> representation. The transform will take an explicit locale as an
>>>>>> argument if you need it to e.g.<@ofbizCurrency locale="en"
>>>>>> amount="10.00"/>
>>>>>>
>>>>>> Regards
>>>>>> Scott
>>>>>>
>>>>>> HotWax Media
>>>>>> http://www.hotwaxmedia.com
>>>>>>
>>>>>> On 27/07/2010, at 8:51 AM, Adrian Crum wrote:
>>>>>>
>>>>>>> Ruth,
>>>>>>>
>>>>>>> Honey attracts flies better than vinegar.
>>>>>>>
>>>>>>> Why would I refuse to help you? I have been responding to all of
>>>>>>> your messages - trying to understand your environment and what you
>>>>>>> are trying to do.
>>>>>>>
>>>>>>> Now that we have determined the version you are using, and we have
>>>>>>> established that you are experiencing the intended behavior in that
>>>>>>> version, we can continue from there.
>>>>>>>
>>>>>>> If you attempt to disable the framework's localization, then you
>>>>>>> won't get to demonstrate the locale support. I believe what you are
>>>>>>> seeking is a context-specific disabling of the localization. In
>>>>>>> that case, you will have to examine each screen to find the
>>>>>>> segments that you want to disable, and then disable localization
>>>>>>> only in those screen segments.
>>>>>>>
>>>>>>> Check the Freemarker docs to see if there is a way to specify a
>>>>>>> locale in numeric-to-string conversions. I'll see if there is
>>>>>>> convenient way to do it in screen widgets.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> On 7/26/2010 1:33 PM, Ruth Hoffman wrote:
>>>>>>>> Hi Adrian:
>>>>>>>> Thank you for your answer. However, I did not ask if this is
>>>>>>>> correct. I
>>>>>>>> asked where this conversion is performed.
>>>>>>>>
>>>>>>>> If you could tell me where this happens you could save me lots of
>>>>>>>> time.
>>>>>>>> But, since you either don't know or refuse to help me in this
>>>>>>>> situation,
>>>>>>>> I simply will thank you.
>>>>>>>>
>>>>>>>> BTW, I'd I'm fully aware that I can disable the language selection
>>>>>>>> screen. I want to avoid that if possible since it is an excellent
>>>>>>>> example of OFBiz providing user/session sensitive locale support.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Ruth
>>>>>>>>
>>>>>>>> Adrian Crum wrote:
>>>>>>>>> The framework is set up to display numbers and dates in the correct
>>>>>>>>> format based on the user's locale setting. So, the behavior you
>>>>>>>>> described is correct. If you don't want the user to select a locale
>>>>>>>>> other than US, then you can disable the locale selection screen.
>>>>>>>>>
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>> On 7/26/2010 12:04 PM, Ruth Hoffman wrote:
>>>>>>>>>> Hi Adrian:
>>>>>>>>>>
>>>>>>>>>> svn info says revision 809901. I do believe it is 9.04.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Ruth
>>>>>>>>>>
>>>>>>>>>> Adrian Crum wrote:
>>>>>>>>>>> So that would make it the 9.04 version?
>>>>>>>>>>>
>>>>>>>>>>> -Adrian
>>>>>>>>>>>
>>>>>>>>>>> On 7/26/2010 11:29 AM, Ruth Hoffman wrote:
>>>>>>>>>>>> Hi Adrian:
>>>>>>>>>>>> #809901 at least that is what svn info says it is.
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Ruth
>>>>>>>>>>>>
>>>>>>>>>>>> Adrian Crum wrote:
>>>>>>>>>>>>> What OFBiz version are you using on your live eCommerce site?
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 7/26/2010 11:00 AM, Ruth Hoffman wrote:
>>>>>>>>>>>>>> Hello Developers:
>>>>>>>>>>>>>> I'm having a problem on my live eCommerce site where, when a
>>>>>>>>>>>>>> user
>>>>>>>>>>>>>> selects any locale other than English, the BigDecimal value
>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>> order
>>>>>>>>>>>>>> item's price is not being converted correctly to a string. For
>>>>>>>>>>>>>> example a
>>>>>>>>>>>>>> Big Decimal value of "10.000" is getting displayed as
>>>>>>>>>>>>>> "10,00" and
>>>>>>>>>>>>>> being
>>>>>>>>>>>>>> passed back in the form as "10,00". I'd like this value to be
>>>>>>>>>>>>>> "10.00" as
>>>>>>>>>>>>>> it is when the locale is set to English. I've spent most of the
>>>>>>>>>>>>>> morning
>>>>>>>>>>>>>> trying to figure out where this is converted done in the
>>>>>>>>>>>>>> code, but
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> little success. Could someone who has worked on this please
>>>>>>>>>>>>>> tell me
>>>>>>>>>>>>>> where to start looking?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> FYI - I tried replicating this on the 9.04 stable release
>>>>>>>>>>>>>> demo site
>>>>>>>>>>>>>> but
>>>>>>>>>>>>>> screen rendering is really messed up so I can't seem to get
>>>>>>>>>>>>>> to a
>>>>>>>>>>>>>> place
>>>>>>>>>>>>>> where I can create a final order to look and see what the
>>>>>>>>>>>>>> values
>>>>>>>>>>>>>> being
>>>>>>>>>>>>>> passed back look like.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> TIA
>>>>>>>>>>>>>> Ruth
>>>>>>>>>>>>>>
>>>>
>>>
>>
smime.p7s
Description: S/MIME cryptographic signature
