[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
