* Return a Result Object from AnnotationsReader::updateDefinition
This is so we can make a decision on whether or not a schema's type or
ref has been manually defined by a user via an `@OA\Schema` annotation
as something other than an object.
If it has been defined, this bundle should not read model properties any
further as it causes errors.
I put this in AnnotationReader as it seemed the most flexible in the
long run. It could have gone in `OpenApiAnnotationsReader`, but then any
additional things added to `updateDefinition` could be left out of the
decision down the road. This is also a convenient place to decide this
once for `ObjectModelDescriber` and `JMSModelDescriber`.
* Stop Model Describer if a Schema Type or Ref Has Been Defined
Via the result object added in the previous commit.
This lets user "short circuit" the model describers by manually defining
the schema type or ref on a plain PHP object or form. For example,
a collection class could be defined like this:
/**
* @OA\Schema(type="array", @OA\Items(ref=@Model(type=SomeEntity::class)))
*/
class SomeCollection implements \IteratorAggregate { }
Previously the model describer would error as it tries to merge the
`array` schema with the already defiend `object` schema. Now it will
prefer the array schema and skip reading all the properties of the
object.
* Add a Documentation Bit on Stopping Property Description
* Mark UpdateClassDefinitionResult as Internal
* Adding ``header_block`` Twig Block
In attempting to remove the default green header from the API docs (I am integrating the docs into a site that already has a header), I have found that the only possible way to do so is to overwrite the entire ``index.html.twig`` file. This is because the existing ``{% header %}`` twig tags are placed *inside* the ``<header>`` HTML tags. So, if one overrides the ``{% header %}`` block, it only adjusts the header content, as opposed to allowing control over the entire header object.
To resolve this problem I considered two methods:
- Move the existing ``{% header %}`` tags _*outside*_ of the ``<header>`` tags. This would resolve the problem in the simplest fashion, but would be a breaking change for those currently overriding the block.
- Add a new twig block, placing its tags *_outside_* the existing ``<header>`` tags. This would leave the existing functionality as-is, and would not break any current implementations.
I chose the latter for the reasons specified above, and suggested the name ``{% header_block %}``. Thanks for considering this proposal.
* Add Location of Original Twig Template
This doc page advises that one can `have a look at the original template to see which blocks can be overridden`, but does not say where the original template can be found. This edit adds that information so that users don't have to resort to searching for keywords (like I just had to).
Note that I haven't run any tests as this is a docs-only change.
If this was turned on by default, that seems like a _large_ BC break as
folks entire OpenAPI doc could change underneath them.
The config option defaults to false and users can enable it if they
desire.
This doc page advises that one can `have a look at the original template to see which blocks can be overridden`, but does not say where the original template can be found. This edit adds that information so that users don't have to resort to searching for keywords (like I just had to).
Note that I haven't run any tests as this is a docs-only change.
* Add new config node disable_default_routes to prevent registering RouteDescriber to specific areas which allowes disabling rendering of default routes, Adjust tests accordingly
* Add documentation for new config variable
* Change disable_default_routes to filter route collection instead of disabling route describer, Add test for new handling in FilteredRouteCollectionBuilder
* Change naming of matching method for disabling default routes
* Fix codestyle issue
* Fix codestyle issue
* Change naming of dataProvider to match testing name
Co-authored-by: Frederik Holz <team-orange@auxmoney.com>
When using serializer context groups in JMS serializer, even if just using the Default group in one place explicitly and leaving it blank in another, they will be treated as different component schemas, even though to the serializer outcome they are the same.
Documenting behavior of decision with side effect.
