commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (BEANUTILS-258) Improve Converter Implementations
Date Tue, 01 May 2007 11:36:16 GMT

    [ 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


Mime
View raw message