Hi all,
first of all I have to say that I'm really happy to see that effort is
being made to come up with a annotation based model binding mechansim.
We've been using our own-grown for a while, but a standard is better! :)
I also think it would be useful to inject "sub models". Using only the
@Inject annotation is ambiguous though, as the class could be either an
OSGi Service or a sub model. A solution for this could be to use an
annotation like @SubModel and make OSGi services the default.
@Inject @SubModel
private ImageModel image; // using the field name as context path for
the sub model as default, in this case ./image
@Inject @SubModel(path="image2") // path explicitly provided, here
./image2
private ImageModel anotherImage;
@Inject // assumed to be an OSGi service for non-primitive types
private SomeOtherClass myService;
-Georg
Am 20.12.2013 15:19, schrieb Justin Edelson:
Hi Konrad,
Thanks for the clarification.
It seems straightforward enough to be able to adapt the injected
value
if it is not assignable to the field's class.
@Inject
private ImageModel image
image would be a Resource object natively which could then be adapted
to the ImageModel class.
Justin
On Fri, Dec 20, 2013 at 8:08 AM, Konrad Windszus <[email protected]>
wrote:
Hi Justin,
let me give a concrete example where switching resource nodes is
actually useful: I do have a composition model of two image models
(i.e. the same class). Obviously they cannot share the same node, as
both models are referring to the same value names. Therefore an
approach similar to <sling:include path="..." resourceType=".."> would
be very useful on the model side. I admit that in the case of models
it is a little bit different, because we are not doing real request
dispatching here. Rather I want to have a way to tell the factory (or
only the ValueMap injector) to act on a certain sub node of the
request resource instead of the request resource itself. That way we
could tell the instance1 of the image model to act on subnode 'image1"
and the instance2 of that model to act on subnode "image2".
Regards,
Konrad
Am 20.12.2013 um 13:41 schrieb Justin Edelson
<[email protected]>:
Hi Konrad,
This makes sense, except for the part about "switch the current
resource"? What do you mean by this? It seems we should be treating
the request resource (which is what I think of as the "current"
resource) as immutable.
Regards,
Justin
On Fri, Dec 20, 2013 at 5:31 AM, Konrad Windszus <[email protected]>
wrote:
Hi Justin,
another useful feature just came to my mind (in fact we are using
it in our own annotation framework) which is composition. Would it
be much effort to allow injecting one model into another?
We do have the following usecase for that (although this is CQ, I
guess there is a similar usecase in Sling only):
You have a model for an image with title, alternative text.
You have a model for multiline text fields and alignment.
There exist resourceTypes for each of the models as well as a
composite resourceType multilineImage.
For the composite resourceType I would like to reuse the existing
models, but I cannot split up the view (i.e. the JSPs and work with
sling:include), because the html is somehow intertwined.
Therefore I would define another composite model exposing the
models for both image and multiline and use that composite model in
my JSP.
It would be great if for the injection of other models it would be
possible to switch the current resource as well (i.e. descent into
subnode image).
That do you think about that?
Thanks in advance,
Konrad
Am 19.12.2013 um 18:07 schrieb Justin Edelson
<[email protected]>:
Hi,
I've published a page to the wiki about a concept I've been
working on
to consolidate the various appproaches I have seen in the wild to
model object creation. I'm calling this YAMF for now, although
ideally
we'll just call it Sling Models :)
Without repeating the whole contents of the wiki page, at a high
level, this is a purely annotation driven approach supporting
both
classes and interfaces. Your model class simply needs to declare
from
which other classes it can be adapted:
@Model(adaptables=Resource.class)
And then annotate the fields (for classes) and methods (for
interfaces) which need injection:
@Inject
private String propertyName;
You can inject properties, OSGi services, request attributes, and
entries from SlingBindings.
New injector types can be created through an SPI.
Additional annotations are supported for special cases:
@Optional - mark a field/method as optional.
@Filter - provide a filter (i.e. for OSGi services)
@Named - specify a name (other than the default field/method
name) to
use for the inejction lookup.
More detail can be found here:
https://cwiki.apache.org/confluence/display/SLING/YAMF+-+Yet+Another+Model+Factory
The working code is up in my whiteboard:
https://svn.apache.org/repos/asf/sling/whiteboard/justin/yamf/
Look forward to your feedback.
Regards,
Justin
