USDollar & Locale fix

[Stephan Eggermont >]

The combination of USDollar and USDollarEditor doesn't work outside
the US.

USDollar does:
private static NumberFormat _currencyFormat =
NumberFormat.getCurrencyInstance();
while USDollarEditor does:
if (!text.startsWith("$")) text = "$" + text;

I changed USDollarEditor to:

import java.text.NumberFormat;
import java.util.Currency;

public int bind(AtomicEObject value)
{
try
{
String text = getText().trim();
String currencySymbol =
NumberFormat.getInstance().getCurrency().getSymbol();
if (!text.startsWith(currencySymbol))
text = currencySymbol +" "+ text;
value.parseValue(text);
return 0;
}
catch (java.text.ParseException ex)
{
value.fireValidationException(ex.getMessage());
return 1;
}
}

In that way it transparantly handles a different currency (and should
probably be renamed to LocalMoney).
The addition of a space was needed for Euro (and is a bug). Currency
doesn't provide enough information to know the position of the
currencysymbol (might be after the number). Another usefull addition
would be to allow the currency code to be used instead of the symbol.

[Eitan Suez]

hi stephan,

  thanks for the fix.  i'll check it in later today.
 
  i think in general the implementation
  could use a bigger overhaul.  the major bug
  with the implementation is that it does not
  avoid floating point rounding errors at the
  moment.  i need to ensure the amount is
  kept in a bigdecimal and stored in a compatible
  database field type.

  separately, it'd be nice if currencies were
  designed from the start with multicurrency
  support in mind.  usdollar at the very least
  should be renamed as you suggest.

  i'll try to target this work for the next release.

/ eitan

[Eitan Suez]

stephan,

  i'm in the process of making the change to USDollarEditor.
  i'm noticing that when the currency is the us dollar,
  putting a space in between the currency symbol
  and the value (as you show) causes the parsing
  to fail.  i.e.:
      Number number = _currencyFormat.parse(stringValue);
  (in USDollar) throws a ParseException.

  did you make changes to USDollar that you didn't mention
  in your email?

thanks,
/ eitan

[Stephan Eggermont >]

I added the space to make the Euro work. That and adding the
currencysymbol worked for values with and without the euro
symbol. Without the space the euro parsing didn't work
if the euro symbol was present. If that doesn't work the same
for dollars I'd suggest doing a few try catches with
symbol+space, symbol, currency code + space and
currency code added.

Stephan

On Mar 13, 6:40 pm, "Eitan Suez" <eitan.s...@gmail.com> wrote:
> stephan,
>
>   i'm in the process of making the change to USDollarEditor.
>   i'm noticing that when the currency is the us dollar,
>   putting a space in between the currency symbol
>   and the value (as you show) causes the parsing
>   to fail.  i.e.:
>       Number number = _currencyFormat.parse(stringValue);
>   (in USDollar) throws a ParseException.
>
>   did you make changes to USDollar that you didn't mention
>   in your email?
>
> thanks,
> / eitan
>

> On Wed, Mar 12, 2008 at 10:34 AM, Eitan Suez <eitan.s...@gmail.com> wrote:
> > hi stephan,
>
> >   thanks for the fix.  i'll check it in later today.
>
> >   i think in general the implementation
> >   could use a bigger overhaul.  the major bug
> >   with the implementation is that it does not
> >   avoid floating point rounding errors at the
> >   moment.  i need to ensure the amount is
> >   kept in a bigdecimal and stored in a compatible
> >   database field type.
>
> >   separately, it'd be nice if currencies were
> >   designed from the start with multicurrency
> >   support in mind.  usdollar at the very least
> >   should be renamed as you suggest.
>
> >   i'll try to target this work for the next release.
>
> > / eitan
>

> > On Wed, Mar 12, 2008 at 5:02 AM, Stephan Eggermont > <step...@stack.nl>

[Stephan Eggermont >]

I'm afraid I don't understand how the parsing of currencies is
supposed to work. Can anyone explain the results of the
following:

package bla;

import java.util.*;
import java.lang.*;
import java.io.*;
import java.text.NumberFormat;
import java.text.ParseException;
import java.util.Currency;

public class CurrencyParsing{

public CurrencyParsing(){}

private static Locale[] locales = Locale.getAvailableLocales();
private static Number res;

public static void test(NumberFormat nf, StringBuffer b, String
parseTest){
try {
res = nf.parse(parseTest);
b.append(res.toString()+"\t");
} catch (ParseException e) {
b.append("no\t");
}
}

public static void main(String[] args){
try {
FileOutputStream fos = new FileOutputStream("test.txt");
OutputStreamWriter osw = new OutputStreamWriter(fos,"UTF8");
String[] val = {"10.00", "10,00", "10.000", "10,000"};
for (int i = 0; i<locales.length; i++){
Locale l = (Locale)locales[i];
NumberFormat nf = NumberFormat.getCurrencyInstance(l);
Currency c = nf.getCurrency();
StringBuffer b = new StringBuffer();
b.append(l.getDisplayCountry()+"\t");
b.append(l.getDisplayVariant()+"\t");
b.append(c.getSymbol()+"\t");
for (int j = 0; j<val.length; j++){
test(nf,b,val[j]);
test(nf,b,c.getSymbol()+val[j]);
test(nf,b,c.getSymbol()+" "+val[j]);
}
osw.write(b.toString()+"\n");
}
osw.close();
} catch (IOException e) {}
}
}

[Stephan Eggermont >]

Ok, I get better results when replacing the
c.getSymbol()
by
c.getSymbol(l)...
[I am in favor of removing getSymbol() instead of having it return the
wrong result...]
but am still unable to parse a.o. Euros from
Portugal, Finland, Belgium, Spain (sometimes), Greece, France,
Germany,
Dollars from Canada, Liras from Turkey.

[Eitan Suez]

i recall ernest recommending looking into:
http://jscience.org/
as they have an api for working with currencies.
i think it's worth investigating.

/ eitan

[Stephan Eggermont >]

It doesn't look like they do currency parsing, just calculations.
UnitFormat.java parses a lot, but not currencies.