Very reasonable indeed. It would probably be good to extend the javadoc of the 
ValueMap at the same time to make clearer what kind of conversions are supposed 
to work.
Konrad

> On 19 Dec 2016, at 12:40, Stefan Seifert <sseif...@pro-vision.de> wrote:
> 
> SLING-6416 revealed a problem in the type conversion logic of the 
> ValueMapDecorator [1] of the Sling API not supporting BigDecimal conversions.
> 
> as the TODO indicates (present there for nearly 8 years) the current 
> conversion logic is not very smart (and not very efficient), and supports 
> less conversions than the JCR value map implementation. in jcr.resource a set 
> of internal converters takes care of the conversion (NumberConverter, 
> CalendarConverter, BooleanConverter etc. [2]).
> 
> the contract of the ValueMap interface does not define which conversions 
> should be supported exactly, but one might expect that a map enhanced with 
> ValueMapDecorator should behave at least for the conversion rules the same 
> way as the JCR value map.
> 
> in this case we should move these converter implementation to the sling API 
> and use them in both ValueMapDecorator and jcr.resource implementation.
> 
> WDYT?
> 
> stefan
> 
> [1] 
> https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/wrappers/ValueMapDecorator.java#L64
> [2] 
> https://github.com/apache/sling/tree/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper
> 
> 

Reply via email to