You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Ruth Hoffman <rh...@aesolves.com> on 2010/07/26 20:00:47 UTC
Where is BigDecimal currency converted?
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
Re: Where is BigDecimal currency converted?
Posted by Scott Gray <sc...@hotwaxmedia.com>.
I'm a little vague on it but I think we are talking about how a given locale represents *any* currency, for example in the US you might talk represent the Euro currency as "10.00" but in France that same currency value might be represented as "10,00". I don't believe the actual currency being used has a bearing on how it is represented (other than the currency symbol) but instead it depends entirely on the locale.
So yes, I believe the input parameter should be returned to the server as "10,00" and then converted to the number "10.00" which I'm pretty sure the conversion framework is capable of doing (is the conversion framework present in 9.04?).
Regards
Scott
On 27/07/2010, at 9:25 AM, Ruth Hoffman wrote:
> Hi Adrian:
> You are correct. That is my problem. I wonder, however - is it really correct to return the form value in the user's local currency? Certainly, it should be displayed that way. As far as OFBiz handling of currency, isn't it "XXX.00" and not "XXX,00"? I understand that the equivalent of a dollar sign might be different or that it is displayed on different sides of the numeric value. But really, should OFBiz replace the period like this? Should "10.95" be returned as "10,95" where the 95 is cents or some decimal equivalent of a dollar?
>
> Just wondering.
> Regards,
> Ruth
>
> 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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
Re: Where is BigDecimal currency converted?
Posted by Ruth Hoffman <rh...@aesolves.com>.
Hi Adrian:
You are correct. That is my problem. I wonder, however - is it really
correct to return the form value in the user's local currency?
Certainly, it should be displayed that way. As far as OFBiz handling of
currency, isn't it "XXX.00" and not "XXX,00"? I understand that the
equivalent of a dollar sign might be different or that it is displayed
on different sides of the numeric value. But really, should OFBiz
replace the period like this? Should "10.95" be returned as "10,95"
where the 95 is cents or some decimal equivalent of a dollar?
Just wondering.
Regards,
Ruth
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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>
Re: Where is BigDecimal currency converted?
Posted by Jacques Le Roux <ja...@les7arts.com>.
Interesting, thanks Scott (and Ruth for pushing on it and Adrian to help)
Jacques
From: "Ruth Hoffman" <rh...@aesolves.com>
> Hi Scott:
> Thanks for you suggestions. I just tried ${orderItem.unitPrice?string("0.###")} with the same results. But, good news,
> ${orderItem.unitPrice?c} works in this situation.
> Thanks so much.
> Regards,
> Ruth
>
> Scott Gray wrote:
>> The Freemarker template is aware of the current locale so I can only guess that it is automatically formatting the BigDecimal
>> before presenting it as a string. You can override this behavior by using ${orderItem.unitPrice?c} or by specifying a specific
>> format such as ${orderItem.unitPrice?string("0.###")} here is the info on it:
>> http://freemarker.sourceforge.net/docs/ref_builtins_number.html
>>
>> You are still calling the rendering a "problem" but as mentioned earlier this is actually the desired default behavior, numbers
>> should be rendered in a locale specific format.
>>
>> Regards
>> Scott
>>
>> On 27/07/2010, at 9:51 AM, 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>
>>
>>
>
Re: Where is BigDecimal currency converted?
Posted by Ruth Hoffman <rh...@aesolves.com>.
Hi Scott:
Thanks for you suggestions. I just tried
${orderItem.unitPrice?string("0.###")} with the same results. But, good
news, ${orderItem.unitPrice?c} works in this situation.
Thanks so much.
Regards,
Ruth
Scott Gray wrote:
> The Freemarker template is aware of the current locale so I can only guess that it is automatically formatting the BigDecimal before presenting it as a string. You can override this behavior by using ${orderItem.unitPrice?c} or by specifying a specific format such as ${orderItem.unitPrice?string("0.###")} here is the info on it: http://freemarker.sourceforge.net/docs/ref_builtins_number.html
>
> You are still calling the rendering a "problem" but as mentioned earlier this is actually the desired default behavior, numbers should be rendered in a locale specific format.
>
> Regards
> Scott
>
> On 27/07/2010, at 9:51 AM, 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>
>>>
>
>
Re: Where is BigDecimal currency converted?
Posted by Scott Gray <sc...@hotwaxmedia.com>.
The Freemarker template is aware of the current locale so I can only guess that it is automatically formatting the BigDecimal before presenting it as a string. You can override this behavior by using ${orderItem.unitPrice?c} or by specifying a specific format such as ${orderItem.unitPrice?string("0.###")} here is the info on it: http://freemarker.sourceforge.net/docs/ref_builtins_number.html
You are still calling the rendering a "problem" but as mentioned earlier this is actually the desired default behavior, numbers should be rendered in a locale specific format.
Regards
Scott
On 27/07/2010, at 9:51 AM, 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>
>>
Re: Where is BigDecimal currency converted?
Posted by Ruth Hoffman <rh...@aesolves.com>.
Hi Scott:
Yes, you have a good point. When I have time, I will see how I can fix
this to be more robust. I just didn't want to spend too much time on it
right now. And I really didn't want to have to disable the language
selection box since it is such a neat feature to showcase.
Thanks again.
Ruth
Scott Gray wrote:
> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>
>
Re: Where is BigDecimal currency converted?
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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
>>>>>>>>>>>>>>
>>>>
>>>
>>
Re: Where is BigDecimal currency converted?
Posted by Ruth Hoffman <rh...@aesolves.com>.
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
>>>>>>>>>>>>>
>>>
>>
>
Re: Where is BigDecimal currency converted?
Posted by Scott Gray <sc...@hotwaxmedia.com>.
The link I gave Ruth explains it, see the very bottom of the ?string section: http://freemarker.sourceforge.net/docs/ref_builtins_number.html#ref_builtin_string_for_number
The number format does't override locale specific formatting, it just guides it.
Regards
Scott
On 27/07/2010, at 10:27 AM, Adrian Crum wrote:
> That's a good point. I will look into that when I have some time.
>
> -Adrian
>
> On 7/26/2010 3:22 PM, Scott Gray wrote:
>> I was a little surprised to hear of the behavior in OFBiz though because if you look at FreeMarkerWorker.makeConfiguration(), it explicitly sets a number format of "0.##########" which should override the default locale formatting.
>>
>> Regards
>> Scott
>>
>> On 27/07/2010, at 10:11 AM, 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
>>>>>>>>>>>>>>>
>>>>>
>>>>
>>
Re: Where is BigDecimal currency converted?
Posted by Adrian Crum <ad...@hlmksw.com>.
That's a good point. I will look into that when I have some time.
-Adrian
On 7/26/2010 3:22 PM, Scott Gray wrote:
> I was a little surprised to hear of the behavior in OFBiz though because if you look at FreeMarkerWorker.makeConfiguration(), it explicitly sets a number format of "0.##########" which should override the default locale formatting.
>
> Regards
> Scott
>
> On 27/07/2010, at 10:11 AM, 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
>>>>>>>>>>>>>>
>>>>
>>>
>
Re: Where is BigDecimal currency converted?
Posted by Scott Gray <sc...@hotwaxmedia.com>.
I was a little surprised to hear of the behavior in OFBiz though because if you look at FreeMarkerWorker.makeConfiguration(), it explicitly sets a number format of "0.##########" which should override the default locale formatting.
Regards
Scott
On 27/07/2010, at 10:11 AM, 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
>>>>>>>>>>>>>
>>>
>>
Re: Where is BigDecimal currency converted?
Posted by Adrian Crum <ad...@hlmksw.com>.
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
>>>>>>>>>>>>
>>
>
Re: Where is BigDecimal currency converted?
Posted by Ruth Hoffman <rh...@aesolves.com>.
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
>>>>>>>>>>>
>>>>>>>>>>>
>
>
Re: Where is BigDecimal currency converted?
Posted by Scott Gray <sc...@hotwaxmedia.com>.
That does make sense :-)
Regards
Scott
On 27/07/2010, at 10:29 AM, Adrian Crum wrote:
> Actually, there is a trick I encountered by mistake a few years back: Have a hidden field named "locale" set to the locale you want. The locale parameter will be passed to the service engine - replacing the user's locale.
>
> -Adrian
>
> On 7/26/2010 3:26 PM, Scott Gray wrote:
>> Yeah understood, I'm guessing people don't often override the default locale specific formatting. The only solution I can think of would be to pass additional locale information in the form (e.g. unitPrice_locale) which the framework could check for and change any conversions to use automatically.
>>
>> Regards
>> Scott
>>
>> On 27/07/2010, at 10:21 AM, Adrian Crum wrote:
>>
>>> Scott,
>>>
>>> Here is the problem I was trying to describe: A user sets their locale to France on a server in the US. Numbers are displayed with spaces instead of commas, and commas instead of periods. A Freemarker template is modified to display numbers in US format instead. So, the user enters 10.95 in an input field and clicks submit. The request parameter will contain the String "10.95" and when that parameter hits the service engine it will be converted to a BigDecimal using the user's locale. A NumberFormatException will be thrown because the String is not in the correct format (it was expecting "10,95").
>>>
>>> That's my theory anyway.
>>>
>>> -Adrian
>>>
>>>
>>> On 7/26/2010 2:20 PM, 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
Re: Where is BigDecimal currency converted?
Posted by Adrian Crum <ad...@hlmksw.com>.
Actually, there is a trick I encountered by mistake a few years back:
Have a hidden field named "locale" set to the locale you want. The
locale parameter will be passed to the service engine - replacing the
user's locale.
-Adrian
On 7/26/2010 3:26 PM, Scott Gray wrote:
> Yeah understood, I'm guessing people don't often override the default locale specific formatting. The only solution I can think of would be to pass additional locale information in the form (e.g. unitPrice_locale) which the framework could check for and change any conversions to use automatically.
>
> Regards
> Scott
>
> On 27/07/2010, at 10:21 AM, Adrian Crum wrote:
>
>> Scott,
>>
>> Here is the problem I was trying to describe: A user sets their locale to France on a server in the US. Numbers are displayed with spaces instead of commas, and commas instead of periods. A Freemarker template is modified to display numbers in US format instead. So, the user enters 10.95 in an input field and clicks submit. The request parameter will contain the String "10.95" and when that parameter hits the service engine it will be converted to a BigDecimal using the user's locale. A NumberFormatException will be thrown because the String is not in the correct format (it was expecting "10,95").
>>
>> That's my theory anyway.
>>
>> -Adrian
>>
>>
>> On 7/26/2010 2:20 PM, 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
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>
Re: Where is BigDecimal currency converted?
Posted by Scott Gray <sc...@hotwaxmedia.com>.
Yeah understood, I'm guessing people don't often override the default locale specific formatting. The only solution I can think of would be to pass additional locale information in the form (e.g. unitPrice_locale) which the framework could check for and change any conversions to use automatically.
Regards
Scott
On 27/07/2010, at 10:21 AM, Adrian Crum wrote:
> Scott,
>
> Here is the problem I was trying to describe: A user sets their locale to France on a server in the US. Numbers are displayed with spaces instead of commas, and commas instead of periods. A Freemarker template is modified to display numbers in US format instead. So, the user enters 10.95 in an input field and clicks submit. The request parameter will contain the String "10.95" and when that parameter hits the service engine it will be converted to a BigDecimal using the user's locale. A NumberFormatException will be thrown because the String is not in the correct format (it was expecting "10,95").
>
> That's my theory anyway.
>
> -Adrian
>
>
> On 7/26/2010 2:20 PM, 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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
Re: Where is BigDecimal currency converted?
Posted by Adrian Crum <ad...@hlmksw.com>.
Scott,
Here is the problem I was trying to describe: A user sets their locale
to France on a server in the US. Numbers are displayed with spaces
instead of commas, and commas instead of periods. A Freemarker template
is modified to display numbers in US format instead. So, the user enters
10.95 in an input field and clicks submit. The request parameter will
contain the String "10.95" and when that parameter hits the service
engine it will be converted to a BigDecimal using the user's locale. A
NumberFormatException will be thrown because the String is not in the
correct format (it was expecting "10,95").
That's my theory anyway.
-Adrian
On 7/26/2010 2:20 PM, 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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>
Re: Where is BigDecimal currency converted?
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
Re: Where is BigDecimal currency converted?
Posted by Adrian Crum <ad...@hlmksw.com>.
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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
Re: Where is BigDecimal currency converted?
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
Re: Where is BigDecimal currency converted?
Posted by Adrian Crum <ad...@hlmksw.com>.
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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Where is BigDecimal currency converted?
Posted by Ruth Hoffman <rh...@aesolves.com>.
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
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Where is BigDecimal currency converted?
Posted by Adrian Crum <ad...@hlmksw.com>.
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
>>>>>
>>>>
>>>
>>
>
Re: Where is BigDecimal currency converted?
Posted by Ruth Hoffman <rh...@aesolves.com>.
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
>>>>
>>>
>>
>
Re: Where is BigDecimal currency converted?
Posted by Adrian Crum <ad...@hlmksw.com>.
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
>>>
>>
>
Re: Where is BigDecimal currency converted?
Posted by Ruth Hoffman <rh...@aesolves.com>.
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
>>
>
Re: Where is BigDecimal currency converted?
Posted by Adrian Crum <ad...@hlmksw.com>.
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
>