Re: [RT] Sling Models as scoped Dependency Injection Framework
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
RE: [RT] Sling Models as scoped Dependency Injection Framework
ok, i've touched multiple different topics in my post, i created 4 ticket for
each of them so we can discuss them further separately:
https://issues.apache.org/jira/browse/SLING-3715
https://issues.apache.org/jira/browse/SLING-3716
https://issues.apache.org/jira/browse/SLING-3718
https://issues.apache.org/jira/browse/SLING-3718
stefan
-Original Message-
From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of
Justin Edelson
Sent: Monday, June 30, 2014 6:16 PM
To: dev@sling.apache.org
Subject: Re: [RT] Sling Models as scoped Dependency Injection Framework
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
