* Add petstore config
* Expand lambda to allow formatting of partials
* Fix order of operation with parenthesis
* Fix not exposing needed enum to string converters
* Add support for form params including files
* Add generated petstore client
* Regenerate existing elm client
* Add script that all files compile successfully
* Remove old unmaintained petstore client
* Add pipeline to try and compile elm clients
* [C++][Pistache] Refactor setupSupportingFiles
Supporting files are set up in the CppPistacheServerCodegen()
constructor as well as in processOpts(). Refactor the code and extract a
method setupSupportingFiles().
* [C++][Pistache] Refactor: Simplify isQueryParam condition
Both branches of the if/else do the same steps. Refactor this out and
invert logic.
* [C++][Pistache] Refactor: Add injectImplInFilename
Both branches of the if/else if do the similar steps and are dependent
on the suffix. Make this obvious by introducing a new method
injectImplInFilename(String result, String suffix).
* [C++][Pistache] Refactor: injectImplInFilename: remove index search
We do not need the separatorChar index to inject the "Impl" string.
Simply truncate the whole string.
Also rename the parameter from 'result' to' filename'.
* CppPistacheServer: Refactor postProcessOperationsWithModels
Pull out the post-processing for a single operation, and also pull out
post-processing for parameters.
Introduce boolean expressions for supported parsing per parameter, and
consumption of JSON.
Reorder code to make locality more explicit i.e. how consumeJSON and
isParsingSupported is generated and used.
* CppPistacheServer: Refactor to use functional matching
Functional matching like anyMatch() directly state what boolean value is
searched.
However, the Predicates deserve to heave names themselves.
* CppPistacheServer: Add base class for Api
Looking at the generated main-api-server.cpp code it gets obvious that
the API classes are self similar with a similar interface.
Only the construction and teh initialization is called in the main()
function. Leverage this fact to create a generalization ApiBase.
Introduce ApiBase as a pure virtual base class to the concrete API
classes and declare init() as virtual.
Pull the route member into the base class.
With this change we could have a container hold all the ApiImpl
objects later and call init() on all of them using a for_each loop.
* CppPistacheServer: Use ApiBase for ApiImpl storage
Refactor the main-api-server template to use a vector for ApiImpl
storage instead of separate objects. This leverages the previously
added ApiBase generalization.
We push all concrete ApiImpl objects into a vector and call init() on
each of them.
* [C++][Pistache]: Update generated sample
Due to teh addition of ApiBase class update the generated sample.
* [C++][Pistache] Add comment for postProcessSingleParam
* [C++][Pistache] Rename and comment implFilenameFromApiFilename
While writing the comment, I realized that the method name could be more
precise. Thus rename injectImplInFilename to implFilenameFromApiFilename
and add comment.
* Fix byte array writing in JSON to be valid base64 string
- remove ToStringFormatArg
- use ToUrlString to path parameters
- use Base64UrlEncode only in ToUrlString
* Use LexToString instead of FString::Format
As discussed in https://github.com/OpenAPITools/openapi-generator/pull/7415#discussion_r1113274416, it seems unlikely the code was correct.
server_operation_index is a hash table. In Ruby, `hash[key]` will return the value associated with `key`. If key is absent, `nil` is returned. Because that is sometimes undesirable, there is also `hash.fetch(key)`, which raises an error if the key is absent. It also allows you to specify a default to fall back on: `hash.fetch(key, default)` will return `default` if the key is absent.
So, since not all users will specify a 'server per operation' (or at least: I'm not), the old code would usually set `index` to the `server_index`, which is initialized to 0. The subsequent `if index == nil` will usually return false (`0 != nil` in Ruby), after which the `server_url` call on line 177 constructs the url based on the `server_operation_variables` and `operation_server_settings`, assuming we are dealing with the case where a server per operation is configured. The case where the url should be constructed from `scheme`, `host`, etc. is only called if either `server_index` is explicitly set to `nil` or the key `operation` is explicitly associated with the value `nil` in the `server_operation_index` hash table, both of which seem inappropriate.
* fix issue 15264
* If useResponseEntity true then keep @Controller if not @RestController
---------
Co-authored-by: Rodrigo Maciel de Almeida <rodrigo.almeida@wefin.com.br>
* if method return type is void then no return
* build the project
* fix build the project
* fix build the project
* fix return
* fix build the project
* fix build the project
* fix build the project
---------
Co-authored-by: Rodrigo Maciel de Almeida <rodrigo.almeida@wefin.com.br>
* Probe content type for multipart form uploads since many servers require each part to correctly identify its type.
* Update samples
* Add explanatory comment
* Update samples with comment
