You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Georg Henzler (JIRA)" <ji...@apache.org> on 2016/05/12 19:34:13 UTC

[jira] [Commented] (SLING-5721) Extend Sling Models to allow mapping of ValueMap values to custom types

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

Georg Henzler commented on SLING-5721:
--------------------------------------

[~kwin] Thanks for your comments in the pull request. I updated the the PR accordingly (including a unit test). Also injection of arrays/lists is supported now (also included in PR update and Unit Test).

> 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
>
> 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)