[jira] [Updated] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

["Dirk Rudolph (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dirk Rudolph updated SLING-6655:
--------------------------------
    Description: 
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

  was:
As far as I understood the the whole story behind Sling Models API is/was that I can be used to adapt {{Adaptable}}s 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? How and why to use them? 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


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