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

Stefan Seifert commented on SLING-3715:
---------------------------------------

thanks!

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

Reply via email to