Hi Konrad, On Tue, Jan 7, 2014 at 10:42 AM, Konrad Windszus <[email protected]> wrote: > 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
done. > - the order in which the injectors are called I agree that this needs better definition. > - 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) @Projection has been renamed to @Via and I added a better example. > - some example code on how to use @Source There's now an example of this on the wiki. > > 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. I've converted the list to a table. @Named isn't injector specific. It is, however, ignored for OSGI services, something which is identified in the table. > > Regarding the OSGiServiceInjector: I did not see the ungetService, therefore > the service reference is probably never released. That's unfortunately correct. What I'm in the process of doing is changing the OSGiServiceInjector so that if the adaptable is a request, it uses SlingScriptHelper intead of the bundle context so at least the references are released if you use a request as the adaptable. But I don't see a good way to handle this otherwise. Any ideas? Regards, Justin > > 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 >>>>>>> >>>>>>> >>>>> >>> >
