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