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 <[email protected]>
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 <[email protected]> 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) <[email protected]>
> > 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)
> > >
> >
>
