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 |
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 > |
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 >> > |
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 >>> >> > |
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 >>>> >>> >> > |
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 >>>>> >>>> >>> >> > |
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 >>>>>> >>>>> >>>> >>> >> > |
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 >>>>>>> >>>>>> >>>>> >>>> >>> >> > |
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) Download Attachment |
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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > |
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) Download Attachment |
In reply to this post by Adrian Crum
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 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > |
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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> smime.p7s (3K) Download Attachment |
In reply to this post by Scott Gray-2
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 >>>>>>>>>>> >>>>>>>>>>> > > |
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 >>>>>>>>>>>> >>>>>>>>>>>> >> >> smime.p7s (3K) Download Attachment |
In reply to this post by Ruth Hoffman-2
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 >>>>>>>>>>>> >> > |
In reply to this post by Scott Gray-2
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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> > |
In reply to this post by Adrian Crum
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 >>>>>>>>>>>>> >>> >> smime.p7s (3K) Download Attachment |
In reply to this post by Adrian Crum
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) Download Attachment |
In reply to this post by Scott Gray-2
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 >>>>>>>>>>>>>> >>>> >>> > |
Free forum by Nabble | Edit this page |