* ContentType selection fix for csharp.
Updated to reflect java implementation. Previously any request body of type string was having the content type overridden to 'application/json'. This prevented custom json ContentTypes
* updated the petshop codegen for C#
* Fixed content type selection test for csharp
* Replaced tabs with 4 spaces
* Removed trailing space / string comparison
* [Elixir Client] Improve primitive typings
* [Elixir Client] Add type to models
Fix following dialyzer warnings in the sample:
```
:0: Unknown type 'Elixir.SwaggerPetstore.Model.ApiResponse':t/0
:0: Unknown type 'Elixir.SwaggerPetstore.Model.Client':t/0
:0: Unknown type 'Elixir.SwaggerPetstore.Model.Order':t/0
:0: Unknown type 'Elixir.SwaggerPetstore.Model.OuterBoolean':t/0
:0: Unknown type 'Elixir.SwaggerPetstore.Model.OuterComposite':t/0
:0: Unknown type 'Elixir.SwaggerPetstore.Model.OuterNumber':t/0
:0: Unknown type 'Elixir.SwaggerPetstore.Model.OuterString':t/0
:0: Unknown type 'Elixir.SwaggerPetstore.Model.Pet':t/0
:0: Unknown type 'Elixir.SwaggerPetstore.Model.User':t/0
```
* Adding a Scalaz codegen client
* Fixing imports and removing commented code
* Adding the bash file and updating the Pet store samples for Scalaz.
* Finalizing Scalaz generation so that it works for the Petstore.yaml
* Removing some unnecessary files and comments
* Removing some files that were accidentally generated for the wrong Scala
* Added support for enums in Dart.
* Pick non-private names for enum values.
The _ prefix denotes a private member in Dart, so avoid generating enum values starting with this character.
* Properly encode enum values into query paramters.
* Various cleanups.
* Add support for x-enum-values extension.
Use class instead of enum for better ergonomy.
Better generated enum names.
* Fixed test.
* Support enum descriptions.
* Updated api client, Required parameters {{#required}} .. {{/required}}, are mapped to Eiffel
Void Safety Rules, optional parameters are translated to detachable TYPE.
Validation Rules are mapped to preconditions, at the moment maximun and minimun
validation has been added.
Improved API_CLIENT.parameter_to_tuple feature to accept a LIST [ANY] instead of LIST [STRING_32].
Improved model template to generate the model output.
* Updated API_CLIENT.parameter_to_string feature, missing STRING representation.
* Updating sample using the latest modifications.
Fixes#5985
We were experiencing syntax issues when generating the Petstore example. See some of the examples below:
StoreApiInterface.php
namespace Swagger\Server\Api;
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;
use Swagger\Server\Model\Order;
**use maparray<string,int>;**
use Symfony\Component\HttpKernel\Exception\BadRequestHttpException;
UserApiInterface.php
public function createUsersWithArrayInput(**User[]** $body);
public function createUsersWithListInput(User[] $body);
As far as I know, it is not possible to use array of objects in this way.
PetApiInterface.php
namespace Swagger\Server\Api;
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;
use Swagger\Server\Model\Pet;
use Symfony\Component\HttpKernel\Exception\MethodNotAllowedHttpException;
use Swagger\Server\Model\ApiResponse;
**use string[];**
use Symfony\Component\HttpKernel\Exception\BadRequestHttpException;
public function findPetsByStatus(string[] $status);
public function findPetsByTags(string[] $tags);
* Add addiitional files from upstream
* Remove mis-added files
* Add additional swift4 initializer for initializing model object with properties.
This change fixes this issue: https://github.com/swagger-api/swagger-codegen/issues/6641
It adds an additional initializer which allows model objects to be initialized using the properties. For exxample, if we had this model:
"ErrorInfo": {
"type": "object",
"properties": {
"code": {
"type": "integer",
"format": "int32"
},
"message": {
"type": "string"
},
"details": {
"type": "array",
"items": {
"type": "string"
}
}
},
"description": "Example Error object"
},
This we generate an initializer for this model object like this:
public init(code: Int?, message: String?, details: [String]?) {
self.code = code
self.message = message
self.details = details
}
* Add hasVars checks around initializers and re-run all scripts to re-generate
Void Safety Rules, optional parameters are translated to detachable TYPE.
Validation Rules are mapped to preconditions, at the moment maximun and minimun
validation has been added.
Improved API_CLIENT.parameter_to_tuple feature to accept a LIST [ANY] instead of LIST [STRING_32].
Improved model template to generate the model output.
* Add addiitional files from upstream
* Remove mis-added files
* Fix compilation issue with Swift4 inline enums.
This change fixes this issue: https://github.com/swagger-api/swagger-codegen/issues/6607
The problem was that I was using "datatype" instead of "datatypeWithEnum" in the model.mustache file.
When you have a the following model property:
"myInlineStringEnum": {
"type": "string",
"enum": [
"inlineStringEnumValue1",
"inlineStringEnumValue2",
"inlineStringEnumValue3"
]
}
Then we were generating:
public enum MyInlineStringEnum: String, Codable {
case inlinestringenumvalue1 = "inlineStringEnumValue1"
case inlinestringenumvalue2 = "inlineStringEnumValue2"
case inlinestringenumvalue3 = "inlineStringEnumValue3"
}
However, when we decode this, we were using type of the enum ("datatype") rather than the enum type itself ("datatypeWithEnum"). So we were generating:
myInlineStringEnum = try container.decodeIfPresent(String.self, forKey: "myInlineStringEnum")
rather than:
myInlineStringEnum = try container.decodeIfPresent(MyInlineStringEnum.self, forKey: "myInlineStringEnum")
