[
https://issues.apache.org/jira/browse/BEANUTILS-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483855
]
Niall Pemberton commented on BEANUTILS-258:
-------------------------------------------
Bradley, thanks for the feedback...
> 1) I think this class should probably be immutable
You're right that there will be thread safety issues if people use these
implementations in the wrong way - I'll change the visibility of the
setDefaultValue() method to "protected" - although part of me thinks if people
use the classes badly (i.e. changing their properties after configuring and
registering a converter) then thats their own fault.
> 2) I don't understand the hardcoded behavior for String.class and
> StringBuffer.class ...[snip] .. it leads to some inconsistent behavior
I think the inconsistency is in how you've implemented your NullConverter. by
just overriding the convertToType() method - you would either need to also
override the convertToString() or getDefault() methods to produce consistent
results. You're right though that the default behaviour for null Strings and
StringBuffer is different - Strings is trying to be backwardly compatible
whereas StringBuffer is new functionality so doesn't have that to consider. I
am thinking that the StringBuffer functionality over-complicates matters though
- more on that below.
3) AbstractConverter doesn't need the concept of a defaultType
Until now none of the BeanUtils converter implementations took any notice of
the "type" passed in the convert method - which means that it wasn't necessary
to supply a value to the convert method for it to work. The default type is
there so that the new converte functionality will work even when the converters
are used in this way - hopefully meaning existing applications won't break.
I take your point about a simpler AbstractConverter implementation - I think
I'm going to remove the StringBuffer functionality since it does over
complicate the implementation.
Niall
> 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]
