[
https://issues.apache.org/jira/browse/SLING-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14112682#comment-14112682
]
Stefan Seifert commented on SLING-3886:
---------------------------------------
yes. same what is usual with OSGi services - have an interface for a service,
and an implementation class which needs some dependencies injected.
but for sling models, with dependencies that can only sling models inject (e.g.
current request, current resource etc.).
testing is easier as well: if such a model is injected into other models using
@Self annotation it can be mocked away if it uses an interface and not the real
class for injection.
> 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)
