[ https://issues.apache.org/jira/browse/BEANUTILS-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492864
]
Niall Pemberton commented on BEANUTILS-258:
-------------------------------------------
OK I've reverted the StringBuffer functionality and reduced the setDefaultValue() method's
visibility as per above comments:
http://svn.apache.org/viewvc?view=rev&revision=534011
http://svn.apache.org/viewvc?view=rev&revision=534013
> Improve Converter Implementations
> ---------------------------------
>
> Key: BEANUTILS-258
> URL: https://issues.apache.org/jira/browse/BEANUTILS-258
> Project: Commons BeanUtils
> Issue Type: Improvement
> Components: ConvertUtils & Converters
> 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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
|