[configuration] Type conversion

[Emmanuel Bourg <eb...@apache.org>]

Hi,

I've been working on the type conversion lately, it's almost complete, I 
still have to refactor the unit tests and write the docs. Here is what I 
plan to commit:

- A new Converter interface is introduced in the o.a.c.c.converter 
package. This interface has a single method designed to convert a value 
into any other type:

public interface Converter
{
     <T> T convert(Class<T> cls, Object value, Object... params) throws 
ConversionException;
}


- the DefaultConverter class in the same package provides a default 
implementation of this interface.

- AbstractConfiguration has a new instance field with get/setters to 
specify the converter to be used. DefaultConverter is used by default. 
Another implementation using BeanUtils or Morph can be used instead (I 
implemented a converter based on BeanUtils as an example but it supports 
only the String->Object conversion).

- internally, DefaultConverter uses a set of package private type 
converters to handle the conversion into a specific type 
(LocaleConverter, DateConverter, etc). The TypeConverter interface looks 
like this :


interface TypeConverter<T>
{
     T convert(Object value, Object... params) throws ConversionException;
}

- the to<Type>() methods in PropertyConverter are removed. I suggest 
renaming the class to PropertyUtils to avoid any confusion with the 
converters.

What do you think?

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [configuration] Type conversion

[Oliver Heger <ol...@oliver-heger.de>]

Emmanuel Bourg schrieb:
> Oliver Heger a écrit :
> 
>> Do we need to specify a date format?
>>
>> Because a configuration file is not intended to be viewed or edited by 
>> an end user we could define our own format (e.g. the format used by 
>> the java.sql date types) and always use it for date <-> string 
>> conversions.
> 
> Properties file are often edited by hand, that's why we have a 
> PropertyConfigurationLayout class to keep the file easily readable by a 
> human being. Also, DataConfiguration already defines a default date 
> format if the user doesn't bother to specify one.
> 
> 
>> This would simplify the API and its use.
> 
> I would agree if the date conversion was a new feature, I'm just keeping 
> the vararg parameter to remain compatible with the existing 
> configuration files.
> 
> Emmanuel Bourg
> 
I agree that the date format should be configurable. But there are 
certainly other alternatives.

For instance, the date format could be a property of the date converter. 
If users have special requirements, they can register a new date 
converter with a different format pattern, overriding the default one.

I would really like to avoid adding a parameter to an interface method 
that is only used by a specific implementation of that interface.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [configuration] Type conversion

[Emmanuel Bourg <eb...@apache.org>]

Oliver Heger a écrit :

> Do we need to specify a date format?
> 
> Because a configuration file is not intended to be viewed or edited by 
> an end user we could define our own format (e.g. the format used by the 
> java.sql date types) and always use it for date <-> string conversions.

Properties file are often edited by hand, that's why we have a 
PropertyConfigurationLayout class to keep the file easily readable by a 
human being. Also, DataConfiguration already defines a default date 
format if the user doesn't bother to specify one.


> This would simplify the API and its use.

I would agree if the date conversion was a new feature, I'm just keeping 
the vararg parameter to remain compatible with the existing 
configuration files.

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [configuration] Type conversion

[Oliver Heger <ol...@oliver-heger.de>]

Emmanuel Bourg schrieb:
> Oliver Heger a écrit :
> 
>> This looks pretty good to me. Just a question about the convert() 
>> methods: What is the meaning of the params var arg parameter and where 
>> do the actual values come from?
> 
> That's the same vararg used currently by PropertyConverter.to(), it's 
> used to specify a date format when converting a value into a Date or a 
> Calendar.
> 
> Emmanuel Bourg
> 
Do we need to specify a date format?

Because a configuration file is not intended to be viewed or edited by 
an end user we could define our own format (e.g. the format used by the 
java.sql date types) and always use it for date <-> string conversions.

This would simplify the API and its use.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [configuration] Type conversion

[Emmanuel Bourg <eb...@apache.org>]

Oliver Heger a écrit :

> This looks pretty good to me. Just a question about the convert() 
> methods: What is the meaning of the params var arg parameter and where 
> do the actual values come from?

That's the same vararg used currently by PropertyConverter.to(), it's 
used to specify a date format when converting a value into a Date or a 
Calendar.

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [configuration] Type conversion

[Oliver Heger <ol...@oliver-heger.de>]

Emmanuel Bourg schrieb:
> Hi,
> 
> I've been working on the type conversion lately, it's almost complete, I 
> still have to refactor the unit tests and write the docs. Here is what I 
> plan to commit:
> 
> - A new Converter interface is introduced in the o.a.c.c.converter 
> package. This interface has a single method designed to convert a value 
> into any other type:
> 
> public interface Converter
> {
>     <T> T convert(Class<T> cls, Object value, Object... params) throws 
> ConversionException;
> }
> 
> 
> - the DefaultConverter class in the same package provides a default 
> implementation of this interface.
> 
> - AbstractConfiguration has a new instance field with get/setters to 
> specify the converter to be used. DefaultConverter is used by default. 
> Another implementation using BeanUtils or Morph can be used instead (I 
> implemented a converter based on BeanUtils as an example but it supports 
> only the String->Object conversion).
> 
> - internally, DefaultConverter uses a set of package private type 
> converters to handle the conversion into a specific type 
> (LocaleConverter, DateConverter, etc). The TypeConverter interface looks 
> like this :
> 
> 
> interface TypeConverter<T>
> {
>     T convert(Object value, Object... params) throws ConversionException;
> }
> 
> - the to<Type>() methods in PropertyConverter are removed. I suggest 
> renaming the class to PropertyUtils to avoid any confusion with the 
> converters.
> 
> What do you think?
> 
> Emmanuel Bourg
> 
> 
This looks pretty good to me. Just a question about the convert() 
methods: What is the meaning of the params var arg parameter and where 
do the actual values come from?

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org