[
https://issues.apache.org/jira/browse/SLING-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14112759#comment-14112759
]
Jason E Bailey commented on SLING-3886:
---------------------------------------
I understand where my misunderstanding occurred. Although I'm still unclear of
the actual use cases that would require this. In the above mentioned example.
{code}
A result = resource.adaptTo(A.class)
{code}
The idea here is to hide the actual class that I am getting returned. It could
be B.class or C.class so to the end developer I have to treat is as the class
that I requested. I see no value of this over just calling B.class directly
unless there's a way to configure the ability to select from a series of
classes that implement A.class in a contextual manner.
> Sling Models: support adapters for models different from the implementation
> class
> ---------------------------------------------------------------------------------
>
> Key: SLING-3886
> URL: https://issues.apache.org/jira/browse/SLING-3886
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Stefan Seifert
> Labels: models
> Fix For: Sling Models Implementation 1.0.8, Sling Models API 1.0.4
>
> Attachments: 140827_SLING-3886_adapters_support.patch
>
>
> currently, as adapter (adaption target) only the implementation class itself
> that is annotated with the @Model annotation is supported (which can be
> either an interface or a class).
> if the model is not just a simple model but a class with more complex
> business logic the following scenario is required:
> * a "service" interface is defined
> * this service interface ist not directly mapped to injected values, but
> provides higher-level method
> * an implementation class with @Model annotation is implemented which gets
> the required values injectd internally, but implements the interface for
> outside access
> this is currently not possible with sling models.
> the attached patch extends the following features:
> * extends the @Model annotation with an optional "adapters" attribute
> * if defined, only the listed adapters are registered for the adapter
> factory, not the implementation class itself (unless it is listed the
> "adapters" attribute as well)
> * in the adapters attribute only the implementation class itself or
> interfaces that it implements or superclasses can be defined
> * with this the scenario above is perfectly possible
> * unit tests included which simulate the bundle add/remove usecases which is
> required to do the indirect implementation class mapping
--
This message was sent by Atlassian JIRA
(v6.2#6252)
