[ 
https://issues.apache.org/jira/browse/SLING-5721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15296237#comment-15296237
 ] 

Justin Edelson commented on SLING-5721:
---------------------------------------

Yeah, after working this through a bit more, I don't think this approach will 
work well. What I would instead suggest is to have some sort of Converter SPI 
which allows for registration of converter services. This is analogous to the 
AttributeConverter interface in JPA.

> Extend Sling Models to allow mapping of ValueMap values to custom types
> -----------------------------------------------------------------------
>
>                 Key: SLING-5721
>                 URL: https://issues.apache.org/jira/browse/SLING-5721
>             Project: Sling
>          Issue Type: New Feature
>          Components: Extensions
>    Affects Versions: Sling Models API 1.2.2
>            Reporter: Georg Henzler
>         Attachments: SLING-5721.patch
>
>
> At the moment it is already possible to map child resources via 
> @ChildResource to a custom type (that itself only needs to be adaptable from 
> that child resource), but for a plain property it is not yet possible: 
> {code}
> @Inject
> com.mycomp.myproj.Link homePath; // jcr property of type String, does not 
> work currently
> @Inject
> com.mycomp.myproj.EventDate eventDate; // jcr property of type Date, does not 
> work currently
> @Inject
> java.util.Date regularDate; // jcr property of type Date, already works due 
> to standard type conversion available in ValueMap
> {code}
> For custom types, the convention would be that there needs to be a public 
> constructor with one argument with the type of the object as returned by 
> valueMap.get(name). That way a custom type can easily work with situations, 
> where the type of the JCR property is not fixed (e.g. if a property can be of 
> type String or Date, the custom type can just provide both constructors).
> {code}
> @ValueMapObject // opposed to @ValueMapValue
> com.mycomp.myproj.Link homePath; // will call constructor new 
> Link(homePathString) if possible as homePath property exists with type String 
> {code}
> Furthermore it should be possible to map JCR array types:
> {code}
> @ValueMapObject 
> List<com.mycomp.myproj.Link> links; // would expect a String[] and should put 
> the corresponding Link objects into a list (if the JCR type is String, it 
> should use that one element to fill the list with one Link
> @ValueMapObject 
> com.mycomp.myproj.Link[] links; // arrays should work in the same way
> {code}
> See github patch for a fairly straight-forward implementation the above 
> approach. An alternative approach would be to extend @ValueMapValue (I'm open 
> for both approaches, @ValueMapObject is more explicit in model classes).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to