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
Description: S/MIME cryptographic signature
