The generation code was ignoring top-level aliases for any language config that
contained "java", which included "javascript", a completely different language.
Changed this to be those configs based on the JavaAbstractGenerator class.
When a spec defines a Model at the top level that is a non-aggretate type (such
as string, number or boolean), it essentially represents an alias for the simple
type. For example, the following spec snippet creates an alias of the boolean
type that for all intents and purposes acts just like a regular boolean.
definitions:
JustABoolean:
type: boolean
This can be modeled in some languages through built-in mechanisms, such as
typedefs in C++. Java, however, just not have a clean way of representing this.
This change introduces an internal mechanism for representing aliases. It
maintains a map in DefaultCodegen that tracks these types of definitions, and
wherever it sees the "JustABoolean" type in the spec, it generates code that
uses the built-in "Boolean" instead.
This functionality currenlty only applies to Java, but could be extended to
other languages later.
The change adds a few examples of this to the fake endpoint spec for testing,
which means all of the samples change as well.
* Updating samples after #5232.
* Fix tests after #5232.
* Fix Javascript client tests.
* JaxRS server: set serverPort only when not given from outside.
* Update JaxRS sample creator scripts to fix serverPort.
* Preliminary test fix for JaxRS server generators.
* Updating samples for JaxRS with Jersey1/2.
* Updating JaxRS samples again.
This adds a `saveCookies` boolean flag to ApiClient. If set to true,
the client will save and return cookies to the server.
This is useful for supporting @SessionScoped beans in Java servers.
Works both in Node.js desktop apps, and in the browser.
Superagent doesn't encode form parameters properly. For example it doesn't encode objects which contain array. The following is a failed test case:
var my_opts = {
'storyId': 65441,
'id': [56, 352]
};
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.
* issues 4554: Handle 204 response and handle deserialize exceptions
* issue-4554: generate javascript client updated template
Used petstore-with-fake-endpoints-models-for-testing.yaml
* use petstore-with-fake-endpoints-models-for-testing.yaml like sh script
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.
