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!
Just for the record and because [configuration] has already been
mentioned in this thread:
One of the next points on my todo list to get [configuration] 2.0 out is
to rework the conversion framework. Currently, we have a big class doing
all kinds of conversions. I am going to change this to have an
extensible converter framework.
I would really love to make use of [beanutils], however, as soon as some
classes of another project become part of your public API, you are tight
to this project. For instance, [configuration] 1.x depends on [lang]
2.x. After the major release of [lang] 3.0, we got many requests to
update the dependency, but this was not possible in a minor release due
to binary incompatible changes - because of the changed package
structure in [lang] the API of [configuration] would also change.
Something similar can happen with [beanutils], too - work on version 2.0
has already started.
Oliver
>
> 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 configurable
>> conversion. Beanutils can be an optional Maven dependency. This doesn't
>> belong in Commons Langs, because that's where the functionality was before
>> migrating to its own BeanUtils project (circa 2001ish).
>> On Aug 1, 2013 7:06 PM, "James Carman" <ja...@carmanconsulting.com> wrote:
>>
>>> 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 PM, Paul Benedict
>>> <paulus.benedic...@gmail.com> wrote:
>>>> 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 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 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 still stores the values internally as Strings. I do not want to
>>>>>> Javadoc the conversion in order to give us flexibility over
>>> representation
>>>>>> if we decide to change it in the future (caching or whatnot).
>>>>>>
>>>>>> I wanted to post here in CTR mode before I or others add APIs like
>>>>>> getLong() and getLongPrimitive(). Since this is a library, I do
>>> believe we
>>>>>> should end up providing such APIs at the record level for primitives.
>>>>>>
>>>>>> /**
>>>>>> * Returns a value by name.
>>>>>> *
>>>>>> * @param name
>>>>>> * the name of the column to be retrieved.
>>>>>> * @return the column value, or {@code null} if the column name is
>>> not
>>>>>> found
>>>>>> * @throws IllegalStateException
>>>>>> * if no header mapping was provided
>>>>>> * @throws IllegalArgumentException
>>>>>> * if the record is inconsistent
>>>>>> * @see #isConsistent()
>>>>>> */
>>>>>> public Boolean getBoolean(String name) {
>>>>>> String s = this.get(name);
>>>>>> return s != null ? Boolean.valueOf(s) : null;
>>>>>> }
>>>>>>
>>>>>> /**
>>>>>> * Returns a value by name.
>>>>>> *
>>>>>> * @param name
>>>>>> * the name of the column to be retrieved.
>>>>>> * @return the column value, or {@code false} if the column name is
>>>>>> not
>>>>>> found
>>>>>> * @throws IllegalStateException
>>>>>> * if no header mapping was provided
>>>>>> * @throws IllegalArgumentException
>>>>>> * if the record is inconsistent
>>>>>> * @see #isConsistent()
>>>>>> */
>>>>>> public boolean getBooleanPrimitive(String name) {
>>>>>> return Boolean.parseBoolean(this.get(name));
>>>>>> }
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>>>>> Java Persistence with Hibernate, Second Edition<
>>>>>> http://www.manning.com/bauer3/>
>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>> Blog: http://garygregory.wordpress.com
>>>>>> Home: http://garygregory.com/
>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
