This PR adds a `jsonifier` argument to the app and api to align it with
other customization options. We also no longer pass it via the operation
object, which brings us closer to operations as data class only.
This PR fixes 'outside of Flask context' errors in our test suite and
contains the following changes:
- `Connexion.request` is now a Connexion `ASGIRequest` instead of a
Flask `request`
- All other tests with a Flask dependency have been updated or split
Failing tests are down to 11.
This PR refactors our tests to prepare the activation of our tests for
our AsyncApp.
The separate commits are atomic, which can be useful for reviewing.
---------
Co-authored-by: Ruwann <ruwanlambrichts@gmail.com>
This PR adds an interface for the ConnexionMiddleware, similar to the
interface of the Connexion Apps.
The Connexion Apps are now a simple wrapper around the
ConnexionMiddleware and framework app, delegating the work to the
middleware. This enables a similar interface and behavior for users when
using either the middleware or apps.
The arguments are repeated everywhere there is a user interface, but are
parsed in a central place. Repeating the arguments is not DRY, but
needed to provide users with IDE autocomplete, typing, etc. They are
parsed in a single `_Options` class, which also provides a mechanism to
set default options on an App level, and override them on the more
granular API level.
This makes the long list of provided parameters a lot more manageable,
so I would like to use it for the `Jsonifier` as well, and re-add the
`debug` and `extra_files` arguments which I have dropped in previous
PRs. I'll submit a separate PR for this.
I renamed the `options` parameter to `swagger_ui_options` since it only
contains swagger UI options. This is a breaking change though, and we'll
need to highlight this upon release.
We still have quite a lot of `App`, `MiddlewareApp`, and abstract
classes. It would be great if we could find a way to reduce those
further, or at least find better naming to make it more clear what each
one does 🙂 .
Finally, I added examples on how the middleware can be used with third
party frameworks under `examples/frameworks`. Currently there's an
example for Starlette and Quart, but this should be easy to extend. They
also show how the `ASGIDecorator` and `StarletteDecorator` from my
previous PR can be used.
* Extract boilerplate code into Routed base classes
* Use typing_extensions for Python 3.7 Protocol support
* Use Mock instead of AsyncMock
* Extract response validation to middleware
* Refactor Request validation to match Response validation
* Factor out shared functionality
* Fix typo in TextResponseBodyValidator class name
* Fix string formatting
* Use correct schema to check nullability in response validation
* Add test for MethodViewResolver
* Warn about ignoring of collection_endpoint_name in MethodViewResolver
* Add docstring on class_arguments in MethodViewResolver
* ensure view_name is CamelCase
* update tests for MethodViewResolver for CamelCase
* use inflection package to camelize
Co-authored-by: Robbe Sneyders <robbe.sneyders@ml6.eu>
* Added MethodViewResolver
By subclassing RestyResolver and modifying its `resolve_function_from_operation_id` method, it is now possible to use automatic routing functionality with Flask's MethodView together with MethodViewResolver.
* Add MethodView example
* Add tests for methodview
* add documentation on how to use MethodViewResolver
