[
https://issues.apache.org/jira/browse/SLING-5721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Henzler updated SLING-5721:
---------------------------------
Description:
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).
was:
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 String[], 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}
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).
> 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)
