When constructing an enum through constructFromObject the original value provided by the API response should be returned rather than extracting the value from the enum name. This resolves an issue where the constructed value is undefined when the name and value are not equivalent.
When a string enumeration has the empty string as one of its available
values, the generated code for many languages is invalid because the
empty string can not be used as an identifier. As with numbers and
symbols, provide a mapping to an English name which can be used as a
replacement. In this case, "empty" for the empty string/empty value.
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
* Add constructFromObject to Javascript enum generation.
Generated code calls constructFromObject on enum types, but enum did not define the necessary function. Returns the value of the enum.
* Update Petstore JS API client
* Add jsdoc for usePromises, add @link for callbacks
* Update petstore samples
* Improve jsdoc for void return type + usePromises
* Add back curly brackets correctly in model template
* Add link to Promise doc in jsdoc comment
* Fix jsdoc annotation for callApi method
The return type annotation was also broken here.
Instead of just ignoring default values in the generated
model constructors, we modify the generator code in Java.
The template checks for null before outputting a default value.
Superagent does not always produce a `body`. See
http://visionmedia.github.io/superagent/ for details. When it
doesn't, we should deserialize the raw `response.text` rather
than returning `null`. Currently, the JS client always returns
`null` when the return type is String! This commit fixes
that.
The `constructFromObject` factory methods should be class methods
(or "static" methods), not instance methods.
With this commit, ApiClient no longer calls the model constructors
directly. Instead, it calls the new static factory method to get the
new instance. If there is no data on the top level, null is returned.
It is still possible for users to call the model constructors
directly, of course.
Fixes#2103.
In the constructFromObject methods, we were always setting all the
parameters, including optional ones that were missing in the `data`
object. Because of the `convertToType` calls, this had the effect
of producing the *strings* `"undefined"` or `"null"` as property
values on the constructed object! This obviously leads to difficult
bugs.
This commit makes sure that we first check that the data field
exists in the data object. Note that both `null` and `undefined`
values will be skipped.
