Where is BigDecimal currency converted?
Locked
12
12
Re: Where is BigDecimal currency converted?
 
|
Re: Where is BigDecimal currency converted?
|
|
Re: Where is BigDecimal currency converted?
|
|
In reply to this post by Adrian Crum
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 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >> |
smime.p7s (3K)
Re: Where is BigDecimal currency converted?
|
|
Re: Where is BigDecimal currency converted?
|
|
In reply to this post by Adrian Crum
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?
|
|
In reply to this post by Ruth Hoffman-2
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?
|
|
Re: Where is BigDecimal currency converted?
Administrator
|
| Free forum by Nabble | Edit this page |