Improve Converter Implementations
---------------------------------
Key: BEANUTILS-258
URL: http://issues.apache.org/jira/browse/BEANUTILS-258
Project: Commons BeanUtils
Issue Type: Improvement
Affects Versions: 1.7.0
Reporter: Niall Pemberton
Assigned To: Niall Pemberton
Priority: Minor
Fix For: 1.8.0
The "Converter" contract has the following signature....
public Object convert(Class, Object)
...which incudes the type (Class) that the value should be converted to.
However all the Converter implementations in BeanUtils ignore this parameter
and always convert to a specific type - for example IntegerConverter only ever
converts to Integer values.
One of the weaknesses in BeanUtils is that conversion of an Object to a String
is almost always done using the toString() method which, depending on the
Class, can produce unhelpful values. IMO all Converter implementations should,
at a minimum, support also support conversion from the type they handle to a
String.
Theres two stages to this process:
1) Enhance Converter implementations to handle conversion to Strings.
2) Modify BeanUtils/PropertyUtils to delegate String conversion to the
Converters.
In order to facilitate this, I'm adding a new AbstractConverter class which
removes the need for duplciated "boiler plate" code. As well as providing a
structure for conversion it also handles missing and invalid values in a
uniform way.
I also have new NumberConverter and DateTimeConverter implementations which
provide improved String conversion facilities:
1) Number Conversion
The existing number Converter implementations use String handling functions
provided by the Number implementation. This has two main drawbacks - they don't
handle String values containing thousand separators and they are fixed using a
period (".") as the decimal separator making them only usable in Locales where
that is the case. I'm adding a number Converter where a pattern can be
specified for the format and/or a Locale specified to use different decimal
symbols. This caters for the alternative Locale scenario and isn't intended to
provide support for applications operating in a multiple Locale environment.
2) Date/Time Conversion
Currently there are only implementations for the java.sql.Date/Time/Timestamp
types - java.util.Date and java.util.Calendar are not handled. I have a
date/time Converter implementation that caters for all of these types. As
people have indicated elsewhere converting from Strings to Date/Calendar poses
problems. This implementation can be configured either to use the default
format for a specified Locale or can be configured with a set of date
"patterns". This may not fully satisfy String <--> Date conversion
requirements, but will at least provide something and importantly will provide
Date conversion factilities where String is not involved (e.g. Date <-->
Calendar).
3) Array Conversion
I also have a generic array Converter implementation. It can convert to/from
Arrays of any type. It does this by delegating the element conversion to a
Converter of the appropriate type. As well as that it also caters for
Collection --> Array conversion and provides addtiona configuraton options for
parsing delimited String.
I'm going to start committing the changes to the Converters initially. If
no-one objects to those, then I'll start looking at improving how
BeanUtils/PropertyUtils uses/delegates to Converters.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
