sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Edelson <jus...@justinedelson.com>
Subject Re: [jira] [Commented] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory
Date Thu, 16 Mar 2017 22:30:47 GMT
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 <dklco@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) <jira@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)
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message