2013/8/2 Oliver Heger oliver.he...@oliver-heger.de
Am 02.08.2013 02:34, schrieb James Carman:
Okay, totally forgot we had ConvertUtils in BeanUtils. So, since we
have the functionality, especially for Strings, and it's extensible,
we could recommend that in the Javadocs perhaps.
That
Am 02.08.2013 02:34, schrieb James Carman:
Okay, totally forgot we had ConvertUtils in BeanUtils. So, since we
have the functionality, especially for Strings, and it's extensible,
we could recommend that in the Javadocs perhaps.
That Converter API is screaming for some generics action!
On Thu, Aug 1, 2013 at 8:23 PM, Paul Benedict pbened...@apache.org wrote:
I can see that we should provide a decorator/delegate (CSVRecordWrapper?)
that has these additional methods and defers them to Beanutils. We should
use our other Commons project to accomplish the pluggable and
I would like to note this CSVRecord addition I am planning on:
public Boolean getBoolean(String name) {
public boolean getBooleanPrimitive(String name)
The method listings are at the end of this message.
What I want to note here is that these are conversion methods and that the
record
Just like the bean mapping I prefer to keep the type conversion out of 1.0.
Emmanuel Bourg
Le 01/08/2013 16:00, Gary Gregory a écrit :
I would like to note this CSVRecord addition I am planning on:
public Boolean getBoolean(String name) {
public boolean getBooleanPrimitive(String
On 1 August 2013 15:21, Emmanuel Bourg ebo...@apache.org wrote:
Just like the bean mapping I prefer to keep the type conversion out of 1.0.
+1
It's definitely not essential to the initial release.
I'm not sure it belongs in CSV at all.
Emmanuel Bourg
Le 01/08/2013 16:00, Gary Gregory a
On Thu, Aug 1, 2013 at 10:30 AM, sebb seb...@gmail.com wrote:
On 1 August 2013 15:21, Emmanuel Bourg ebo...@apache.org wrote:
Just like the bean mapping I prefer to keep the type conversion out of
1.0.
+1
It's definitely not essential to the initial release.
It's one of those things
I agree with Gary. This sounds like a useful feature that doesn't seem to
be to hard to implement. And if he (Gary) has the time to do the necessary
coding, why not?
The only thing I don't like is the getBooleanPrimitive(String) method. I
think it is enough to have a getBoolean(String) that
On Thu, Aug 1, 2013 at 3:45 PM, Benedikt Ritter brit...@apache.org wrote:
I agree with Gary. This sounds like a useful feature that doesn't seem to
be to hard to implement. And if he (Gary) has the time to do the necessary
coding, why not?
The only thing I don't like is the
Le 01/08/2013 21:45, Benedikt Ritter a écrit :
I agree with Gary. This sounds like a useful feature that doesn't seem to
be to hard to implement. And if he (Gary) has the time to do the necessary
coding, why not?
Because you start with getBoolean(), then you add getInt(), getDate(),
getList(),
On 1 August 2013 23:32, Emmanuel Bourg ebo...@apache.org wrote:
Le 01/08/2013 21:45, Benedikt Ritter a écrit :
I agree with Gary. This sounds like a useful feature that doesn't seem to
be to hard to implement. And if he (Gary) has the time to do the necessary
coding, why not?
Because you
None of these methods document exceptions if the conversion fails (eg, not
an integer). Also, how strict is the conversion? Can x represent boolean
false or is that an exception?
On Aug 1, 2013 9:00 AM, Gary Gregory garydgreg...@gmail.com wrote:
I would like to note this CSVRecord addition I am
You might want to think of a conversion addon package using Common
BeanUtils. That project is skilled at conversions from String and has
pluggable capability to customize conversion types.
On Aug 1, 2013 6:51 PM, Paul Benedict pbened...@apache.org wrote:
None of these methods document exceptions
Perhaps it belongs in Commons Lang?
Anything like this that you try to put together is going to blow up
really quickly, by the way (registering new converter types, etc.). I
don't see how having a few little helper methods in CSV is that big of
an issue, personally.
On Thu, Aug 1, 2013 at 7:59
I can see that we should provide a decorator/delegate (CSVRecordWrapper?)
that has these additional methods and defers them to Beanutils. We should
use our other Commons project to accomplish the pluggable and configurable
conversion. Beanutils can be an optional Maven dependency. This doesn't
Okay, totally forgot we had ConvertUtils in BeanUtils. So, since we
have the functionality, especially for Strings, and it's extensible,
we could recommend that in the Javadocs perhaps.
That Converter API is screaming for some generics action!
On Thu, Aug 1, 2013 at 8:23 PM, Paul Benedict
16 matches
Mail list logo
