* [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.
* [C++][Pistache] fix Wconversion warning
* [C++][Pistache] fix struct model compilation with std::optional
* [C++][Pistache] Add validation to struct model
* fix(cpp-pistache-server): meson/cmake build
* fix(cpp-pistache-server): Upgrade to C++17 and use std::optional
* feat(cpp-pistache-server): Disable running tests during build of nlohmann/json
* feat(samples): Update server/petstore/cpp-pistache
* BUG FIX: A missing semicolon in cpp-pistache-server generated code.
* BUG FIX: Provide default values of schema in cpp-pistache-server generated code.
* BUG FIX: Provide default values of schema in cpp-pistache-server generated code.
* Continuing from #1317 and its PRs for pistache server string enum code generation;
* A class that has an `anyOf` specification, in cpp side will have no members: in stead it should have a member having the type `classname_anyOf`
* Thus, Its `==` operator is not present or wrongly filled
* An string enum, should have a better usage, hence the `setEnumValue`
* this PR, is a brigde between `stringenumclassname_anyOf` and `stringenumclassname`
* `anyOf` specification is not just about `Enums`, so a better handling is needed from mustache templates, hence new template model parameter `isStringEnumContainer`
* PR fix: muttleyxd: `double semicolon`
* PR fix: wing328: `I think std::string is C++ only. What about adding x-is-string-enum-container instead in the postProcessModel operation in the C++ pistache server generator?`
* PR fix: wing328: `I think std::string is C++ only...` after fix get latest codes and then generate samples
Co-authored-by: Mehmet Fatih <mfyuce@netas.com.tr>
* fix compilation break with validate function
* fix error handling in handleParsingException
bug caused all errors to be regarded as an internal server error
* generate samples
* overhaul pistache templates
* fix function signature in model-source
return type now aligns with definition in model-header
* use default keyword for destructors
* generate pistache samples
* move bin/configs/other/cpp-pistache-server-cpp-pistache.yaml to bin/configs/cpp-pistache-server-cpp-pistache.yaml
* Only generate validation body if necessary
* generate pistache samples
* Fix not processing enums in cpp-pistache-server
Defining a reusable enum as a component schema results in an empty
class. Following changes are made:
- activate 'postProcessModelsEnum' in 'AbstractCppCodegen'
- modify model templates for the 'cpp-pistache-server' project
As 'postProcessModelsEnum' is now available in the 'AbstactCppCodegen'
the 'enumVars' variables are now available in mustache templates for all
cpp based code generators.
As the 'AbstractCppCodegen' was touched all cpp based
samples were updated.
* fixes encountered on real world
* PR fixes
Co-authored-by: mfyuce <mfyuce@netas.com.tr>
