Paul,
Agreed, the current ConverterService design isn't convenient (hence the
deprecation). The reason you give is good, another one is the lack of proper
integration with content negotiation.
Your suggestion regarding the map of ConverterService is interesting.
However, how would you handle the reverse conversion (from Representation to
Object) ? Instead of a map, maybe we could have a list of converters ordered
by priority.
Each service would have methods such as :
- canConvert(Representation/Variant rep)
- canConvert(Object object)
Sometimes the list of available variants is closely related to the
processing resource, so it may be that the Resource subclass is the best
place to handle such conversions. My vote for now is to keep
ConverterService deprecated in 1.1 instead of refactoring it.
Best regards,
Jerome
2007/11/24, Paul J. Lucas <[EMAIL PROTECTED]>:
>
> The current architecture of ConverterService is such that if I want
> to convert to/from an object of a given class, I subclass
> ConverterService. Well, what if I want to convert to/from several
> classes? In my subclass, I could do an:
>
> if ( obj instanceof MyClass1 ) {
> // ...
> } else if ( obj instanceof MyClass2 ) {
> // ...
> } else ...
>
> which is (a) tedious and (b) means I have to have my subclass know
> about lots of classes (bad design, IMHO).
>
> So instead, why doesn't Application instead have a:
>
> Map<Class,ConverterService>
>
> so then the code to to conversion would look up the right
> ConverterService based on the class of the object being converted?
>
> - Paul
>
