* 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
* Add support for php attributes
* Fix tests for php 8.1
* Simplify the annotations
* Revert the changes to the tests
* CS
* Test FOSRest parsing of attributes
* CS
* typo
* CS
* Test fetchArticle php 8.1 attributes
* Fix namespaces
Co-authored-by: Guilhem Niot <guilhem@gniot.fr>
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.
*Context*: NelmioApiDocBundle does not require clients to have the symfony/validator package. However it requires it in its dev dependencies.
*Problem*: If client of library does not have symfony/validator and uses PHP8, NelmioApiDocBundle will assume that symfony/validator is installed, in `SymfonyConstraintAnnotationReader.php`
*Solution*: We should not assume that client has symfony/validator. So before reading attributes of this class, we now try to see if class exists.
- Tests still run.
- Tested in a project without symfony/validator and requiring this version, it now works.
The error before this fix was :
Exception: `ClassNotFound`
Message for me: `Attempted to load class "Constraint" from namespace "Symfony\Component\Validator".
Did you forget a "use" statement for e.g. "JsonSchema\Constraints\Constraint" or "Doctrine\DBAL\Schema\Constraint"?`
*Context*: NelmioApiDocBundle does not require clients to have the symfony/validator package. However it requires it in its dev dependencies.
*Problem*: If client of library does not have symfony/validator and uses PHP8, NelmioApiDocBundle will assume that symfony/validator is installed, in `SymfonyConstraintAnnotationReader.php`
*Solution*: We should not assume that client has symfony/validator. So before reading attributes of this class, we now try to see if class exists.
- Tests still run.
- Tested in a project without symfony/validator and requiring this version, it now works.
The error before this fix was :
Exception: `ClassNotFound`
Message for me: `Attempted to load class "Constraint" from namespace "Symfony\Component\Validator".
Did you forget a "use" statement for e.g. "JsonSchema\Constraints\Constraint" or "Doctrine\DBAL\Schema\Constraint"?`
Previously it was possible to set only one of the min or max values and
get a schema like:
"property": {
"type": "integer",
"minimum": 1,
"maximum": 0
}
Also possible that `Range` would be used with {min,max}PropertyPath and
you'd get a schema with both minimum and max set to zero.
With the checks in place, that's no longer the case.
It's possible to set a count constraint with a min but no max, which
would generate an OpenAPI Schema like...
"property": {
"type": "array",
"minItems": 1,
"maxItems": 0
}
With this change the schema will only set `minItems` in that example.
* Apply `enum` from Choice Constraints to Items When Choice is Multiple
Otherwise JSON schema like this is generated:
```
"property": {
"type": "array",
"enum": ["one", "two", "three"],
"items": {
"type": "string"
}
}
```
With this change, however, this schema is generated:
```
"property": {
"type": "array",
"items": {
"type": "string",
"enum": ["one", "two", "three"]
}
}
```
A possible downside here is that the symfony constraint stuff happens
before types are figured out from PHPDoc. So it's _possible_ to end up
with something that won't validated. Take something like this:
```
/**
* @Assert\Choice(multiple=true, choices={"..."})
* @var string
*/
```
This would generate:
```
"property": {
"type": "string",
"items": {
"enum": ["..."]
}
}
```
* Fix CS
* cs
* more cs
* fix tests
Co-authored-by: Guilhem Niot <guilhem@gniot.fr>
Sometimes folks will set a `min` length without a max, for instance and
the generated open api schema would previously have been nonsense:
```
"property": {
"type":"string",
"maxLength":0,
"minLength":1
}
```
