If you are going to adapt to the interface, lets say using


then its the ImplementationPicker that will reduce available implementations to 
a single implementation type. According to 


the list of implementations is sorted by natural ordering and with 


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.


> 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)

Reply via email to