[
https://issues.apache.org/jira/browse/SLING-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson resolved SLING-3715.
-----------------------------------
Resolution: Fixed
> Sling Models: Support for class-based dependency injection
> ----------------------------------------------------------
>
> Key: SLING-3715
> URL: https://issues.apache.org/jira/browse/SLING-3715
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Reporter: Stefan Seifert
> Assignee: Justin Edelson
> Priority: Minor
> Labels: models
> Fix For: Sling Models Implementation 1.0.8, Sling Models API 1.0.4
>
> Attachments: 140820_SLING-3715_sling-object-injector.patch
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> Currently Sling Models dependency injection is primary based on parameter
> name-based injection, and not on class-based injection (the latter is more
> common in Spring and comparable frameworks).
> here is Justins opinion on this topic (from the mailing list) and why he
> prefers name-based injection:
> {quote}
> Hi Stefan,
> The big problem IMHO with injecting by class vs. name is that by class
> is too ambigious in many cases. For example, in AEM, it is relatively
> common to want to inject a Page object, but in fact there are two
> different page objects which come into play (currentPage and
> resourcePage) and getting the wrong one could be highly problematic.
> You are correct that things like the request and response could
> presumably be injected by class rather than by name, but the question
> then becomes how do we judge these cases? In my opinion, the bindings
> names are sensible. I personally don't find myself wanting to write
> this very often:
> {code:java}
> @Inject
> private SlingHttpServletRequest somenameOtherThanRequest;
> {code}
> \[...\]
> Regards,
> Justin
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
