Unified data types [actualType and subType]
Updated tests.
JMS parsing fixes; updated {Validator,FormType}Parser, FOSRestHandler, and AbstractFormatter, and updated DataTypes enum.
Modified dataType checking.
Updated tests.
Updated DataTypes enum.
Quick fix and added doc comments.
CS fixes.
Refactored FormTypeParser to produce nested parameters. Updated tests accordingly.
Logical and CS fixes.
Sub-forms and more tests.
Logical and CS fixes.
Swagger support: created formatter.
Configuration and resourcePath logic update.
ApiDoc annotation update. Updated formatter and added tests.
Parameter formatting.
Added tests for SwaggerFormatter.
Added option in annotation, and the corresponding logic for parsing the supplied values and processing them in the formatter.
Routing update.
Updated tests.
Removed unused dependency and updated doc comments.
Renamed 'responseModels' to 'responseMap'
Update the resource filtering and formatting of response messages.
Updated check for 200 response model.
Ignore data_class and always use form-type to avoid conflicts.
Fix: add 'type' even if '' is specified.
Refactored responseMap; added parsedResponseMap. Added tests and updated some.
Fix: add 'type' even if '' is specified.
Initial commit of command.
Finished logic for dumping files.
Updated doc comment; added license and added more meaningful class comment.
Array of models support.
This is the result of https://github.com/nelmio/NelmioApiDocBundle/issues/410.
This PR aims to provide a uniform way of declaring data-types of parameters for
parsers and handlers to follow. In turn, this would allow formatters to
determine data-types in a cleaner and less volatile manner. (See use-case that
can be improved with this PR:
https://github.com/nelmio/NelmioApiDocBundle/blob/master/Formatter/AbstractFormatter.php#L103)
This is possible by the addition two properties to each property item in
`response`, and `parameters` fields in each API endpoint produced by the
`ApiDocExtractor`:
* `actualType` Contains a value from one of the `DataTypes` class constants.
* `subType` Can contain either `null`, or any other `DataTypes` class constant.
This is relevant when the `actualType` is a `DataTypes::COLLECTION`, wherein
`subType` would specify the type of the collection items. It is also relevant
when `actualType` is a `DataTypes::MODEL`, wherein `subType` would contain an
identifier of the model (the FQCN or anything the parser would wish to specify)
Examples:
```php
array(
'id' => array(
'dataType' => 'integer',
'actualType' => DataTypes::INTEGER,
'subType' => null,
),
'profile' => array(
'dataType' => 'object (Profile)',
'actualType' => DataTypes::MODEL,
'subType' => 'Foo\Entity\Profile',
'children' => array(
'name' => array(
'dataType' => 'string',
'actualType' => DataTypes::STRING,
'subType' => null,
),
'birthDate' => array(
'dataType' => 'date',
'actualType' => DataTypes::DATE,
'subType' => null,
),
)
),
'languages' => array(
'dataType' => 'array of strings',
'actualType' => DataTypes::COLLECTION,
'subType' => DataTypes::STRING,
),
'roles' => array(
'dataType' => 'array of choices',
'actualType' => DataTypes::COLLECTION,
'subType' => DataTypes::ENUM,
),
'groups' => array(
'dataType' => 'array of objects (Group)',
'actualType' => DataTypes::COLLECTION,
'subType' => 'Foo\Entity\Group',
),
'profileRevisions' => array(
'dataType' => 'array of objects (Profile)',
'actualType' => DataTypes::COLLECTION,
'subType' => 'Foo\Entity\Profile',
),
'address' => array(
'dataType' => 'object (a_type_a_custom_JMS_serializer_handler_handles)',
'actualType' => DataTypes::MODEL,
'subType' => 'a_type_a_custom_JMS_serializer_handler_handles',
),
);
```
When a formatter omits the `dataType` property or leaves it blank, it is
inferred within `ApiDocExtractor` before everything is passed to formatters.
The service is private so getting it from the container get() method is invalid and it does not work anymore in Symfony 2.5 because the service gets inlined.
When no groups are given in the ApiDoc, there should be no GroupExclusion and the Entity should be parsed wihtout exclusions.
Otherwise only the "Default" group of the Entity would be parsed, which may not be used.
The ApiDoc should not enforce the Entity to be grouped with "Default", to generate a "full-view" of it.
Sometimes required parameters are not used through routing but still they are mandatory. I wanted to have API with
resource.json?foo=bar&something=else
format, that was possible through QueryParam annotation or requirements in routing BUT!
There was no way to set dataType or description
This PR solves problem for me.
Side note: if you want to declare e.g. _format requirement through Annotation or any other param that is used in url ({foo} format) then it won't work. Because Bundle still overrides requirements and parameters after the constuctor in ApiDoc is called. This might be solved in separate PR by adding check if given requirements or parameters was already defined.
