Anyone else out there converting input into currency stored as BigDecimals?
Using numberConverter doesn't cut it since it seems to want to return
either a Long or a Double wrapped as a Number, and I don't see the
point in wrapping all of my business bean accessor methods in
Hi Mike!
My current thinking is to subclass NumberConverter to be a
NumberAsBigDecimalConverter, which should work for my use case. Is
there enough interest out there for me to add this as a tomahawk
component?
You can change you model to accept java.lang.Number, but I am sure you
know
in the very near future.
-Original Message-
From: Mario Ivankovits [mailto:[EMAIL PROTECTED]
Sent: Friday, May 05, 2006 2:24 PM
To: MyFaces Discussion
Subject: Re: currencyConverter - BigDecimal storage
Hi Mike!
My current thinking is to subclass NumberConverter
On 5/5/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
What about a NumberConverter where you can add the wanted return type as
attribute.
Maybe.
The problem is that the return types have to be predefined in order to
insure there's no data loss. For example:
public Object
On 5/5/06, Julian Ray [EMAIL PROTECTED] wrote:
How about creating a CurrencyConverter which would have configurable and
localizable currency formats as well as style for positive and negative
values etc. Is there any value in this?
If we could drum up a list of requirements I would be willing
We had a similar issue. We have all our currencies defined as Doubles
currently, but we would get errors on values that resolved to Longs
(ex. 1.0). We had to create our own converter that always converted
the Number to a Double.
We wanted to extend the existing number converter just like you
On 5/5/06, Geoff Longo [EMAIL PROTECTED] wrote:
We had a similar issue. We have all our currencies defined as Doubles
currently, but we would get errors on values that resolved to Longs
(ex. 1.0). We had to create our own converter that always converted
the Number to a Double.
We wanted to
On 5/5/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
you'd extend the original NumberConverterTag, give it a new
converter-id, and that'd pretty much be it. And you'd need to add a
tld entry. I don't think there's a lot to it than some busy-work.
Also, you'd need to define accessors for
Mike Kienenberger schrieb:
with user-configurable return types.
Maybe it would be worthwhile to make this into a sandbox component
In fact, we could probably just call it t:numberConverter and add a
return type attribute to it.
+1
9 matches
Mail list logo
