[
https://issues.apache.org/jira/browse/SLING-5721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300180#comment-15300180
]
Konrad Windszus edited comment on SLING-5721 at 5/25/16 3:16 PM:
-----------------------------------------------------------------
Since the patch does not include an actual implementation of the ValueConverter
SPI I don't really know how useful that is. What kind of converters would be
shipped then with Sling Models OOTB? IMHO the adaptation mechanism should be
one of those ValueConverters.
I would still prefer an approach where Collections would not have to be
implemented for each injector individually but rather that logic should be part
of the Converter SPI, but to be honest, I don't have a good idea on how to
achieve that.
Also the approach is incompatible with all injectors currently checking for the
requested type.
was (Author: kwin):
Since the patch does not include an actual implementation of the ValueConverter
SPI I don't really know how useful that is. What kind of converters would be
shipped then with Sling Models OOTB? IMHO the adaptation mechanism should be
one of those ValueConverters.
I would still prefer an approach where Collections would not have to be
implemented for each injector individually but rather being part of the
injector, but to be honest, I don't have a good idea on how to achieve that.
It is also incompatible with all injectors currently checking for the requested
type.
> 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-valueconverter-spi.diff, 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)
