Ensure the same date format string is used throughout the generated code (use the one set in Configuration.swift).
Ensure the same date formatter options are used when encoding dates as well as decoding dates. If a consumer has set their own date formatter on CodableHelper, use that when encoding dates too.
Adds DateFormatTests to the SWIFT4 unit tests.
Updates the SWIFT4 petstore samples
* 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
