Diría que estás tratando de resolver el problema. Por lo general, persisto enums como cadenas y, por lo tanto, evito este problema en primer lugar. El inconveniente es, por supuesto, un campo DB más grande, pero eso no es significativo.
Dicho esto:
Yo diría que es posible en general, pero no de una manera limpia. Lo que haría es permitir que todas estas enumeraciones implementen una interfaz común (ya sea solo una interfaz de marcador o una que contenga el método int getId()
). Ahora registre su PropertyEditor solo para esta interfaz, entonces no está rompiendo demasiada funcionalidad estándar.
Luego, su siguiente problema es que se basa en métodos de fábrica estáticos, lo que no se puede hacer de forma genérica. Por supuesto, su PropertyEditor puede hacer:
enumClass.getDeclaredMethod("withId", int.class).invoke(id)
pero me gustaría llamar a ese poco limpia. ¿Qué tal algo como esto:
Object target = null;
for(Object e : EnumSet.allOf(yourEnumClass)){
if(e instanceof MyInterface && ((MyInterface)e).getId()==thisId){
target = e;
break;
}
}
return target;
Ahora que no está utilizando cualquier método de fábrica estática y que tienen compilar tiempo de seguridad, siempre y cuando sus enumeraciones implementan una interfaz común.
Actualización: con el nuevo convertidor de SPI se hace más fácil. Utilice a custom ConverterFactory:
public class CustomEnumConverterFactory implements
ConverterFactory<String, Enum<?>>{
@Override
public <T extends Enum<?>> Converter<String, T> getConverter(
final Class<T> targetType){
return WithId.class.isAssignableFrom(targetType)
? new EnumWithIdConverter(targetType)
: new StandardEnumConverter(targetType);
}
}
Registro de esta manera:
<bean id="conversionService"
class="org.springframework.context.support.ConversionServiceFactoryBean">
<property name="converters">
<!-- converters is a set of both converters and converterfactories -->
<bean class="foo.bar.CustomEnumConverterFactory" />
</property>
</bean>
+1. Me gusta especialmente que esté _ "evitando cambios debido a la orden/nombre" _ –