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.
Updated deprecated MinLength assertion to Length
Updated array of object parsing
Handled deprecated calls because of using
AbstractType (not sure if it is the best way, though)
