call as_view in methodresolver

[bluebrown]

Signed-off-by: Nico Braun rainbowstack@gmail.com

Fixes #1549

Warning
this is a breaking change
users will be required to change any search method to a get method, merging get by id and get collection into a single handler

The primary reason for this change is to be able to use method decorators as described here: https://flask.palletsprojects.com/en/2.1.x/views/#decorating-views

Changes proposed in this pull request:

• change the MethodResolver to call as_view on the classes

[bluebrown]

I did not really find out how to write a test for this. All tests have passed. I think this kind of functionality is currently not covered. Like there is no app created to see what the methods return. Or perhaps, I overlooked it.

[bluebrown]

We, should probably also update the documentation on this.

[coveralls]

Pull Request Test Coverage Report for Build 2489119200

• 22 of 28 (78.57%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.07%) to 94.27%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
connexion/resolver.py	22	28	78.57%

Totals
Change from base Build 2416536603:	-0.07%
Covered Lines:	2665
Relevant Lines:	2827

---

💛 - Coveralls

[RobbeSneyders]

Thanks @bluebrown.

• The changes look good to me in general. I left one small comment on the example.
• We should indeed update the docs on this. Could you have a look?
• As mentioned in the issue, it would be good to still offer a resolver with the old behavior, but we can mark it deprecated.
• The example currently doesn't run on main since we're in the middle of a large refactoring (Move functionality into pluggable ASGI middleware stack #1489), but the resolver itself does seem to work correctly. I submitted a PR which fixes the blocking issue (Use resolver in security middleware #1553).
• The current resolver tests indeed only check the generated operation_id, which is unchanged. I'll have a deeper look at the tests later to see how we can best add a test for the changed behavior.

[RobbeSneyders]

This needs a body argument to work.

[bluebrown]

I have updated the example to use the body param in post and put

[bluebrown]

• added a way to use the old resolver as DeprecatedMethodViewResolver
• added a class_arguments parameter to the new MethodViewResolver to allow dependency injection
• updated the tests to test both resolvers with the existing tests via parameterized fixture
• updated the example app
• updated the docs

[RobbeSneyders]

Thanks for the changes @bluebrown.
I left one comment, but overall changes look great.

I still need to find the time to have a look at how we can add an additional test for the resulting behavior,

[RobbeSneyders]

Could we name this a bit more specific eg. view_arguments?
It would also be good to document it here as an argument on top of the documentation you already added.

[bluebrown]

I think class_arguments is more fitting because the arguments for the view function are also called class_args and class_kwargs. That's because these arguments are passed to the class when instantiating it.

[bluebrown]

I will try to add a comment to the init function. I had actually one already with example usage, but the pre-commit hook didn't like it.

[RobbeSneyders]

Thanks @bluebrown. I'll merge this one and submit a test as a separate PR as we need to rebase on main anyway to make it work. I'll tag you there.