Hi Justin, thanks for the additions. It would be great if you could extend the documentation in the wiki with the following information: - which injectors are available for which adaptables - the order in which the injectors are called - some more information about @Projection (when it is necessary to call it, i.e. if a desired injector can only act on a child object of the adaptable) - some example code on how to use @Source
Maybe a table with the different injectors in the rows and the behaviour in terms of the injection-specific annotations like @Named, @Filter as well as the supported adaptable would be the best. Regarding the OSGiServiceInjector: I did not see the ungetService, therefore the service reference is probably never released. Cheers, Konrad On 24 Dec 2013, at 22:16, Justin Edelson <[email protected]> wrote: > 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 >>>>>> >>>>>> >>>> >>
