If you are going to adapt to the interface, lets say using resource.adaptTo(DoesStuff.class)
then its the ImplementationPicker that will reduce available implementations to a single implementation type. According to https://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l53 <https://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l53> the list of implementations is sorted by natural ordering and with https://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ResourceTypeBasedResourcePicker.java?view=markup#l59 <https://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ResourceTypeBasedResourcePicker.java?view=markup#l59> the first implementation type in that order, assuming resource is of resourceType “test/rt”, will be placed into the resourceType mapping Map. So it will be Type3. On the other hand, if Type3 is in bundle A and Type7 in bundle B where bundle B is started before bundle A, when you are using getModelFromResource(resource) not the first in alphabetical order, but in order of appearance will be returned, in that case 7. /Dirk > On 20 Mar 2017, at 03:44, Daniel Klco <dk...@apache.org> wrote: > > That's a pretty accurate summary and yes, this would make sense as a Lambda. > > I do wonder how the current implementation would handle if one were to > register two sling models against the same resource type and interface? > Would the returned model be predictable? For example if I had: > > public interface DoesStuff { > int random(); > } > > @Model(adaptable=Resource.class, resourceType="test/rt") > public class Type3 implements DoesStuff{ > public int random(){ > return 3; > } > } > > @Model(adaptable=Resource.class, resourceType="test/rt") > public class Type7 implements DoesStuff{ > public int random(){ > return 7; > } > } > > If I adapted a resource of type test/rt to the DoesStuff interface, would > it return 3 or 7? Thus the idea of returning a collection so that any > registered Sling Models would be processed. > > Regards, > Dan > > On Thu, Mar 16, 2017 at 6:30 PM, Justin Edelson <jus...@justinedelson.com> > wrote: > >> Hi Dan, >> I don't think I'm understanding how that API would work. >> >> You have a single Resource there and a single Class (which I assume is >> actually an interface for your use case). Are you saying that for one >> Resource, there would be multiple Model classes implementing that same >> interface mapped to the same resourceType? >> >> I have seen code which does something like this (which I think is closer to >> what your first paragraph is describing): >> >> Resource -> collect children to make a list -> adapt each item in the list >> to some interface -> remove the null values -> return the list >> >> This is pretty easy to do with Lambdas. Maybe we should have a separate >> module (which can require Java 8) to provide some Functions/Predicates... >> >> Justin >> >> On Thu, Mar 16, 2017 at 4:57 PM Daniel Klco <dk...@apache.org> wrote: >> >>> I do think though that there's a ton of value in the concept of being >> able >>> to tie SlingModels to a resource type. I agree that this API is clunky, >> but >>> the idea of limiting based on resourceType in Sling Models was really >>> missing. I am using this concept for a library I have in progress right >> now >>> so that developers can "register" sling Models with a particular >> interface >>> against particular resourceTypes. My library then traverses down a >> resource >>> tree, adapting the objects and generating a representation of the tree >> for >>> a DataLayer representation. This works with the current functionality but >>> could be cleaner. >>> >>> What I would really like to be able to do is something like this: >>> >>> Collection<T> models = modelFactory.getModelsByResourceType(Resource >>> resource, Class<?> T); >>> >>> I would expect the method to use both the Class and the Resource type to >>> generate the collection of models which match the requested class and are >>> applicable for the resourceType. Does that make more sense? >>> >>> Thanks, >>> Dan >>> >>> On Thu, Mar 16, 2017 at 3:34 PM, Dirk Rudolph (JIRA) <j...@apache.org> >>> wrote: >>> >>>> >>>> [ https://issues.apache.org/jira/browse/SLING-6655?page= >>>> com.atlassian.jira.plugin.system.issuetabpanels:comment- >>>> tabpanel&focusedCommentId=15928701#comment-15928701 ] >>>> >>>> Dirk Rudolph commented on SLING-6655: >>>> ------------------------------------- >>>> >>>> The difference is that its not obvious to understand what the purpose >> of >>> a >>>> certain piece of the implementation is. Anyway, would you be so kind >> and >>>> point us to the right place where those methods are used for >> Handlebars? >>> I >>>> guess there is a JSR-223 compliant implementation somehow exposing >>>> adaptTo() or the ModelFactory to the scripts themself. IMHO that one is >>>> responsible for finding the right adapterType instead of enforcing 1:1 >>>> resourceType to adapterType. >>>> >>>>> Remove untyped getModelFrom* methods from ModelFactory >>>>> ------------------------------------------------------ >>>>> >>>>> Key: SLING-6655 >>>>> URL: https://issues.apache.org/ >> jira/browse/SLING-6655 >>>>> Project: Sling >>>>> Issue Type: Wish >>>>> Affects Versions: Sling Models Impl 1.3.0 >>>>> Reporter: Dirk Rudolph >>>>> >>>>> As far as I understood the the whole story behind Sling Models API >>>> is/was that it can be used to adapt ordinary objects to typed objects. >>> With >>>> adding {{Object getModelFromResource(...)}} and >>>> {{getModelFromRequest(...)}} this paradigm has been broken. Just >> looking >>> at >>>> the API, what is the purpose of that methods? I agree that it makes >> much >>>> sense to have a binding between the resourceType of {{Resource}} and >>> maybe >>>> even {{SlingHttpServletRequest}} and a model, but this resulting into >> an >>>> ordinary object from API perspective makes it kind of pointless. >>>>> I propose: >>>>> * mark them as deprecated as already done in SLING-6652 >>>>> * let them throw {{UnsupportedOperationException}} to prevent them >>>> being used >>>>> * remove them in the next major API release >>>>> * move the logic of "finding the nearest implementation by >>> resourceType* >>>> to {{ResourceTypeBasedResourcePicker}} >>>>> and for the exporter: >>>>> * if a {{@Model}} has an {{@Exporter}} implicitly registered it with >>> the >>>> {{implType}} as {{adapterType}}, if not already done >>>>> * use the {{implType}} in the {{ExporterServlet}} to adapt from >> request >>>> or {{Resource}} to the model object >>>> >>>> >>>> >>>> -- >>>> This message was sent by Atlassian JIRA >>>> (v6.3.15#6346) >>>> >>> >>
