Hi Dan,
> The problem I see is that there's not a way to override the ordering of
the models beyond changing the name of the Model class or priority of the
bundle
That's true, but you can still override the selection logic by implementing
your own ImplementationPicker to return the right
Hey Justin,
I don't see why it would be an overly common use case. The problem I see is
that there's not a way to override the ordering of the models beyond
changing the name of the Model class or priority of the bundle. Both of
which could have other effects. I could easily see a problem whereby
If you are going to adapt to the interface, lets say using
resource.adaptTo(DoesStuff.class)
then its the ImplementationPicker that will reduce available implementations to
a single implementation type. According to
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
[
https://issues.apache.org/jira/browse/SLING-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15929516#comment-15929516
]
Dirk Rudolph commented on SLING-6655:
-
I see your point now, thanks.
To summarise the discussion
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
[
https://issues.apache.org/jira/browse/SLING-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15929029#comment-15929029
]
Justin Edelson commented on SLING-6655:
---
bq. The difference is that its not obvious to understand
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
[
https://issues.apache.org/jira/browse/SLING-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15928701#comment-15928701
]
Dirk Rudolph commented on SLING-6655:
-
The difference is that its not obvious to understand what the
[
https://issues.apache.org/jira/browse/SLING-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15928674#comment-15928674
]
Justin Edelson commented on SLING-6655:
---
bq. Ok I see but as far as I can see handlebars is not yet
[
https://issues.apache.org/jira/browse/SLING-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15928664#comment-15928664
]
Dirk Rudolph commented on SLING-6655:
-
Ok I see but as far as I can see handlebars is not yet
[
https://issues.apache.org/jira/browse/SLING-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15928654#comment-15928654
]
Justin Edelson commented on SLING-6655:
---
Handlebars is the most obvious case where typing is not
[
https://issues.apache.org/jira/browse/SLING-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15928646#comment-15928646
]
Justin Edelson commented on SLING-6655:
---
Also, I don't see where SLING-6652 talks about deprecating
[
https://issues.apache.org/jira/browse/SLING-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15928645#comment-15928645
]
Dirk Rudolph commented on SLING-6655:
-
By example? The only one that would come to my mind is
[
https://issues.apache.org/jira/browse/SLING-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15928634#comment-15928634
]
Justin Edelson commented on SLING-6655:
---
These methods exist for loosely typed scripting languages
15 matches
Mail list logo
