[jira] [Commented] (SLING-3886) Sling Models: support adapters for models different from the implementation class

["Jason E Bailey (JIRA)" <ji...@apache.org>]

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

Jason E Bailey commented on SLING-3886:
---------------------------------------

I'm having a hard time understanding the use case for what you are describing. From what you are stating it appears that you want to have an implementation of a service with injected fields?

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