You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Buuhuu <gi...@git.apache.org> on 2017/03/16 18:32:56 UTC
[GitHub] sling pull request #204: Feature/sling 6652
GitHub user Buuhuu opened a pull request:
https://github.com/apache/sling/pull/204
Feature/sling 6652
This pull requests enables 1 to many binding from resourceType to model.
IMHO the implementation is quite ugly because of the way resourceType binding is defined. In the current interface the untyped methods getModelFromResource(Resource) and getModelFromRequest(SlingHttpServletRequest) have been added to ModelFactory. Those are not conform to the way the ModelFactory implementation work: creating a typed object from something. I understood that the usecase for the jackson exporter doesn't require a typed object as exporting an ordinary one works quite well but it makes hard to decide which adapterType should be used in case multiple are registered for a single resourceType. Having said that I deprecated those methods along with related ones but still supporting their expected functionality only with a slightly different as adapterTypes are now sorted alphabetically the same way its done for the original adapter implementations. Anyway removing those, or throwing USOE would make much sense to make the API clean again. Most of the code added to Adapter
Implementations can and should be moved to the ImplementationPicker using it which is supposed to decide which implementation to use based on the adaptable's resourceType. For the exporter a slightly adjusting would be required which is now also implemented. Keeping in mind that class level annotations are not inherited there is a 1:1 relation between @Exporter and its implementation class and with that we can implicitly add the implType to the adapterTypes if not already present. As the implType is known to the ExporterServlet anyway it can use it to get the typed object for exporting.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/Buuhuu/sling feature/SLING-6652
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/sling/pull/204.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #204
----
commit f8f0b144bab782e3039eefb9317b20e2147ef508
Author: Dirk Rudolph <di...@netcentric.biz>
Date: 2017-03-16T18:00:41Z
SLING-6652: extended ModelFactory by deprecating untyped methods using the resourceType binding and adding typed equivalent ones
commit 87de04c0f8519cfc47910e9bdb51dc2a21a3013a
Author: Dirk Rudolph <di...@netcentric.biz>
Date: 2017-03-16T18:03:29Z
SLING-6652:
- updatd dependecy to latest snapshot of the models api
- intorduced new data strcture to store multiple adapterTypes/adapter implementations per resource type
- adapted AdapterImplementations to new data structure
- implemented new typed methods defined at ModelFactory using AdapterImplementations
- adapted UnitTest to new, alphabetical order of registered adapter types per resource type
commit a910cae0ecc6a8471a9eb302938bf21872f1569a
Author: Dirk Rudolph <di...@netcentric.biz>
Date: 2017-03-16T18:07:07Z
SLING-6652:
- reverted formatting changes
commit 2dbc3b4d395672834793dc989f44440f4af7221f
Author: Dirk Rudolph <di...@netcentric.biz>
Date: 2017-03-16T18:10:09Z
SLING-6652:
- reverted formatting changes
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] sling pull request #204: Feature/sling 6652
Posted by Buuhuu <gi...@git.apache.org>.
Github user Buuhuu closed the pull request at:
https://github.com/apache/sling/pull/204
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---