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