[ 
https://issues.apache.org/jira/browse/SLING-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15928664#comment-15928664
 ] 

Dirk Rudolph edited comment on SLING-6655 at 3/16/17 7:06 PM:
--------------------------------------------------------------

Ok I see but as far as I can see handlebars is not yet officially supported by 
sling (not even in contrib and SLING-2919 has been closed with Won't fix). 

Anyway from my perspective its in the responsibility of the scripting 
implementation then to decide which adaption they want to make if they don't 
know the type. Wdyt?


was (Author: diru):
Ok I see but as far as I can see handlebars is not yet officially supported by 
sling (not even in contrib and scripting itself). 

Anyway from my perspective its in the responsibility of the scripting 
implementation then to decide which adaption they want to make if they don't 
know the type. Wdyt?

> 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