Thanks everyone for your feedback. I've updated both the wiki and implementation to include support for: * declaring an injection as being provided specifically by a particular injector, using the @Source annotation (as well as adding this annotation to @Filter) * composition support (without new annotations) * switched package to .annotations from .api * using BundleTracker rather than BundleListener * a new injector type for child resources
I also tried to add some reference information to the wiki. I think this captured all of the feedback received so far. Thanks again. Justin On Sat, Dec 21, 2013 at 1:47 AM, Georg Henzler <[email protected]> wrote: > 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 >>>>> >>>>> >>> >
