I agree. I missed that the interface to implement determines the type
already and the autoApply attribute therefore realizes this case.
regards
Bernd
Am 16.01.2012 22:31, schrieb michael keith:
> I am fine with annotating the converter class instead of adding the
> @Converter annotation to the entity class, although I don't see that
> there are too many use cases for needing to define the target
> convertable class name. The type parameter of the converter will define
> the one that it is intended to convert, and for the most part will be
> enough. Two cases that I can think of that *might* warrant an additional
> type parameter are:
> a) You want to map both the primitive and wrapper types (e.g. boolean
> and Boolean). Not sure how often this would occur in practice.
> b) You want to convert a class and all its subclasses. A subclass might
> actually have additional state, though, so the conversion might not be
> sufficient.
>
> I don't believe (a) is all that useful, really. It is probably
> reasonable for people to either add another converter for the primitive
> type or put a @Convert annotation on it.
>
> Similarly for (b), an empty converter subclass could be added to handle
> each convertible type subclass.
>
> I was also thinking that string names for the converters are shorter but
> less typesafe than just using the class name of the converter.
>
> Example:
>
> @Converter
> public class BooleanToIntegerConverter implements
> AttributeConverter<Boolean, Integer> { ... }
> @Converter(autoApply=true)
> public class EmployeeDateConverter implements
> AttributeConverter<com.acme.EmployeeDate, java.sql.Date> { ... }
>
> @Entity
> public class Employee {
> @Id long id;
> @Convert(com.acme.BooleanToInteger.class)
> boolean fullTime;
> ...
> // Automatically applied
> EmployeeDate startDate;
> }
>
> On 16/01/2012 12:05 AM, Bernd Müller wrote:
>> Hi,
>>
>> I would advocate for Lindas proposal, giving some additional
>> unique/global/local arguments
>>
>> Am 12.01.2012 01:49, schrieb Linda DeMichiel:
>>> Are there any additional comments on this proposal?
>>>
>>> If so, please post them now.
>>>
>>> If not, I will proceed to add this to the spec.
>>>
>>> thanks,
>>>
>>> -Linda
>>>
>> I see a problem: the name of the converter is unique in the pu but
>> the usage mimics locality for an entity.
>>
>> In JSF there is also a converter annotation called FacesConverter
>> doing similar things. However it is used to annotate the converter (as
>> the name implies ?)
>>
>> The refactored example:
>>
>> @Converter("booleanToInteger")
>> public class BooleanToIntegerConverter implements
>> ...
>> }
>>
>> @Entity
>> public class Employee {
>> @Id long id;
>> @Convert("booleanToInteger")
>> boolean fullTime;
>> ...
>> }
>>
>> The Converter annotation uses "value" instead of "name" and is therefore
>> a little bit less verbose.
>> And the usage of "booleanToInteger" reflects its uniqueness instead
>> of doubling the string literal in one single entity class.
>>
>> To demand for global application of the converter there is a second
>> attribute "forClass" in @Converter defining the Class to apply for.
>>
>> Example
>>
>> @Converter(forClass=SomeBusinessPropertyType.class)
>> public class ConverterForSomeBusinessPropertyType {
>> ...
>> }
>>
>> @Entity
>> public class Employee {
>> ...
>> SomeBusinessPropertyType sbpt; // Converter applied automatically
>> ...
>> }
>>
>>
>> regards
>>
>> Bernd
>>
>>