[
https://issues.apache.org/jira/browse/SLING-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14112695#comment-14112695
]
Justin Edelson commented on SLING-3886:
---------------------------------------
[[email protected]] Out of curiosity, could you explain the rationale
behind "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)"
Why wouldn't the implementation class *always* be registered as an adapter?
I actually don't feel strongly one way or the other, but this does seem
potentially confusing.
> 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)
