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:
@Inject
private SlingHttpServletRequest somenameOtherThanRequest;
The self injector is interesting. I held off on that initially because
it seems too easy to create a circular injection. Any thoughts on how
that can be avoided?
I'm certainly open to patches which broaden the scope for constructor
injection and @PreDestroy.
Regards,
Justin
On Mon, Jun 30, 2014 at 10:13 AM, Stefan Seifert <sseif...@pro-vision.de> wrote:
> in the last days we played around with Sling Models as underpinning of our
> views in a Sling+Sightly based application. it works fantastic. but during
> our experiments we detected that we were not using Sling Models for accessing
> resource content, i.e. we are not adapting resources to models to access its
> data. this is not required when using JSP or Sightly because you can access
> the properties directly. but we were using Sling Models as Dependency
> Injection frameworks for our java controller classes which are used behind
> the views, which need access to scoped objects of the current request like
> resource resolver and others. and if those controller classes need other
> business classes which depend on scope objects, we use Sling Models injection
> for them as well.
>
> a very simple example for illustration:
>
> this is a controller class behind the view:
>
> @Model(adaptables = SlingHttpServletRequest.class)
> public class MyController {
>
> @Inject
> private MyBusinessClass businessClass;
>
> private String result;
>
> @PostConstruct
> protected void activate() {
> result = this.businessClass.calculateTheResult();
> }
>
> public String getResult() {
> return this.result;
> }
>
> }
>
> and this is the business classes used by the controller
>
> @Model(adaptables = SlingHttpServletRequest.class)
> public class MyBusinessClass {
>
> @Inject
> private ResourceResolver resourceResolver;
>
> public String calculateTheResult() {
> // access resources using resource resolver
> return "myResult";
> }
>
> }
>
> effectively we can use Sling Models to navigate through a hierarchy of loose
> coupled POJOs all using DI for getting the dependencies they need - much like
> in Spring. we have already dependency injection in Felix SCR/OSGi? that's
> right, but only for OSGi services, and not for "scoped" objects depending on
> a current request or resource resolver instance.
>
> using the adapter concept to adapt the controller and business classes from
> the scope object they depend on (e.g. from SlingHttpServletRequest for
> request scope, from ResourceResolver if they need access to resources in
> context of a JCR user session etc.) they get all scope context objects they
> need, and those that can be adapted from them. and of course it's still
> possible to inject OSGi services as well.
>
> out of the box the sample displayed above will not work with Sling Models - a
> small custom injector is required:
>
> @Component
> @Service
> @Property(name = Constants.SERVICE_RANKING, intValue = 50)
> public class SelfAdaptInjector implements Injector {
>
> public String getName() {
> return "selfadapt";
> }
>
> public Object getValue(Object pAdaptable, String pName, Type pType,
> AnnotatedElement pElement, DisposalCallbackRegistry pCallbackRegistry) {
> if (!(pType instanceof Class)) {
> return null;
> }
> if (!(pAdaptable instanceof Adaptable)) {
> return null;
> }
> return ((Adaptable)pAdaptable).adaptTo((Class<?>)pType);
> }
>
> }
>
> which effectively supports navigation through a graph of objects which share
> the same scope adaptable. using another custom injector which allows indirect
> adaption from SlingHttpServletRequest->ResourceResolver->CustomClass it is
> possible to have classes that can be used both in request scope, and in
> ResourceResolver-only scope as well (the latter may be a resource resolver
> instance which is opened in context of an OSGi service or event handler).
> this is already possible via "via", but i want to avoid boilerplate code as
> much as possible for much-used context objects.
>
> additionally all relevant "context" objects that can be derived from the
> adaptable should be supported for injection. Justin already added in
> SLING-3700 as custom injector for resource resolver, but it should support
> others as well, e.g. injecting the request, the response etc. and in my
> opinion this should be done primary using detection by class type, not by
> property name (this can be controlled already by injector ordering and custom
> injectors).
>
> if Sling is running in other context like AEM an AEM specific injector can
> ensure that AEM-typical context objects are available as well (again Justin
> has an example for this in AEM commons, although based on property names and
> not on class types).
>
> to be even more Spring-like and support developers with Spring background it
> would be nice to support other Spring-typical features as well, e.g.
> constructor dependency injection (currently only supported for the adaptable
> itself) and JSR-250 @PreDestroy annotation. all this should not be an big
> issue, because most infrastructure is already there in the current codebase.
>
> is it worth to make this a core feature for Sling Models, and propagate it in
> documentation etc.?
>
> WDYT?
>
> stefan
