* [Swift] Update Alamofire version and update tests and Swift version to 4.2 for default and RxSwift variants
* Update promiseKit for Swift 4.0
* Update project files.
* Merge branch 'master' of https://github.com/OpenAPITools/openapi-generator into OpenAPITools-master
# Conflicts:
# samples/client/petstore/swift4/default/SwaggerClientTests/SwaggerClient.xcodeproj/project.pbxproj
* Merge in latest master
* Remove typo in bash file
* update all swift samples
* fix method name starting with number literal
* better handling of operationId starting with number
* update swift 4 samples
Co-authored-by: Akihito Nakano <sora.akatsuki@gmail.com>
Co-authored-by: Jeremie Bresson <dev@jmini.fr>
Co-authored-by: Jim Schubert <james.schubert@gmail.com>
Co-authored-by: Martin Delille <martin@phonations.com>
Co-authored-by: Tomasz Prus <tomasz.prus@gmail.com>
Co-authored-by: William Cheng <wing328hk@gmail.com>
* Split up model template into partials
* Change models from class to struct.
This fixes issue https://github.com/swagger-api/swagger-codegen/issues/6941.
In this change, we make our Swift4 generated model objects struct instead of class. However, in order to do this, we needed to handle the following edge cases:
* Inheritance and polymorphism (allOf)
* With classes, we use inheritance. So therefore, the parent properties are ONLY on the parent generated class, and the model object which derives from the parent class picks up those properties through inheritance.
* However, structs do not support inheritance. So we simply duplicate the parent allOf properties in the child struct.
* We have to handle the case where the property name on the struct may be different than the property name in the JSON. By default, the Codable protocol assumes that the JSON property name is the same as the struct property name. If they need to be different, then we generate a CodingKeys string enum, which contains the mapping between struct property name and JSON property name.
* additionalProperties. We cannot use the default Codable implementation for the additionalProperties, since it will look for an actual dictionary called "additionalProperties" in the JSON. Therefore, for model objects which have additionalProperties, we must generate our own implementation for the Decodable and Encodable protocols.
I have run ./bin/swift4-all.sh and ./bin/swift4-test.sh to re-generate all of the sources, and I have verified that the generated code in samples/clients/test/swift4/default builds and the unit tests pass.
* Update VERSION in .swagger-codegen
* Update generated code for swift4-test schema
* update versions of dependencies on swift4 and swift3
* change syntax for swift4
* run petstore script
* change enum case from UpperCamel to lowerCamel
* remove unneeded break statements
* avoid wrapping conditionals in parentheses
* avoid force casting
* run pod update on petstore/swift4/rxswift
* update project for swift 4
* run swift4-petstore-all.sh
* fix compile error
* avoid use iso8601 date strategy for encoder / decoder
* resolve file references
* 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
* 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")
Previously, we had implemented the Codable protocol by simply claiming conformance, and making sure that each of our internal classes also implemented the Codable protocol. So our model classes looked like:
class MyModel: Codable {
var propInt: Int
var propString: String
}
class MyOtherModel: Codable {
var propModel: MyModel
}
Previously, our additionalProperties implementation would have meant an object schema with an additionalProperties of Int type would have looked like:
class MyModelWithAdditionalProperties: Codable {
var additionalProperties: [String: Int]
}
But the default implementation of Codable would have serialized MyModelWithAdditionalProperties like this:
{
"additionalProperties": {
"myInt1": 1,
"myInt2": 2,
"myInt3": 3
}
}
The default implementation would put the additionalProperties in its own dictionary (which would be incorrect), as opposed to the desired serialization of:
{
"myInt1": 1,
"myInt2": 2,
"myInt3": 3
}
So therefore, the only way to support this was to do our own implementation of the Codable protocol. The Codable protocol is actually two protocols: Encodable and Decodable.
So therefore, this change generates implementations of Encodable and Decodable for each generated model class. So the new generated classes look like:
class MyModel: Codable {
var propInt: Int
var propString: String
// Encodable protocol methods
public func encode(to encoder: Encoder) throws {
var container = encoder.container(keyedBy: String.self)
try container.encode(propInt, forKey: "propInt")
try container.encode(propString, forKey: "propString")
}
// Decodable protocol methods
public required init(from decoder: Decoder) throws {
let container = try decoder.container(keyedBy: String.self)
propInt = try container.decode(Int.self, forKey: "propInt")
propString = try container.decode(String.self, forKey: "propString")
}
}
class MyOtherModel: Codable {
var propModel: MyModel
// Encodable protocol methods
public func encode(to encoder: Encoder) throws {
var container = encoder.container(keyedBy: String.self)
try container.encode(propModel, forKey: "propModel")
}
// Decodable protocol methods
public required init(from decoder: Decoder) throws {
let container = try decoder.container(keyedBy: String.self)
propModel = try container.decode(MyModel.self, forKey: "propModel")
}
}
* Fix build error in Xcode 9 beta 3, as .compact is no longer defined
* Add test schema for Swift 4 and associated script and config files
* Add test app for swift4Test.json schema
* Make integer, Integer, int, and Int32 types map to Swift Int type instead of Int32 type
* Add CodingKeys to model template, which allows us to serialize/deserialize variable names that are different than property names
* Make updates to Swift 4 test schema
* Fixes for unit test app for swift4Test.json Swift 4 test schema
