[
https://issues.apache.org/jira/browse/SLING-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15293650#comment-15293650
]
Justin Edelson commented on SLING-5739:
---------------------------------------
bq. Generally, I think it will almost always be better to create its own model
for those use cases (flattening into one Pojo on java side what is structured
in the JCR will not make the code better readable or maintainable).
In many cases I agree, but creating a separate model for one or two properties
doesn't really make sense.
bq. It would fairly easy to extend @ResourcePath to lookup the resource's
ValueMap and use the target property name to lookup the value to inject.
As with SLING-5726, I think this is the wrong separation of concerns, but we
obviously have a difference of opinion there.
bq. Certainly, this would be more light-weight than introducing another fairly
complicated ViaProvider SPI.
I'm not sure the SPI should be characterized as "complicated" :) It's two
methods. Could be one, but I wanted to use classes to select the type to help
with IDE code completion.
> [Sling Models] Allow for extensible @Via providers
> --------------------------------------------------
>
> Key: SLING-5739
> URL: https://issues.apache.org/jira/browse/SLING-5739
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Justin Edelson
>
> Currently, @Via support in Sling Models is limited to JavaBean properties. It
> would be useful to be able to extend this and allow for downstream projects
> to add new @Via providers.
> Proposing to support this by extending the @Via annotation
> {code}
> @Via(value = "jcr:content", type = ChildResource.class)
> {code}
> The default type is BeanProperty (the current behavior).
> New providers can be added by implementing a ViaProvider SPI and provide a
> marker class for use in the annotation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
