* JS add oneOf support
* add validate json method
* add oneOf support to JS client
* update samples
* add todo in anyof
* switch to composed.oneOf
* update oneOf to support primitive types
* update messages
* minor fix, add more tests
* update samples
* fix npe in from model
* fix syntax error in length check
* update samples
* restore js tests
* test only js in circleci
* trigger build failure
* Revert "trigger build failure"
This reverts commit 7e8c34e8234a87660590f95e2f761b026edb1d4f.
* Revert "test only js in circleci"
This reverts commit e261429339a062077fadfeabfda02aaef30308af.
* add discriminator property, mapping
* add discriminator, mapping support to R client generator
* add discriminator, mapping support to R client genrator httr library
While working with the Magento 2.4 API definition, there were several
issues found. The easiest to resolve is a documentation naming issue.
(The others will be raised for discussion.)
This is known to be an issue with query parameters, but may not be
limited to *just* query parameters.
In the event that a parameter is a mix of arrays and objects, the
template in the documentation for the API function was expanding out the
parameter name such that `foo[0]` would be turned into
`:foo_left_square_bracket0_right_square_bracket`, but the actual
parameter name was being left as `:foo[0]`, which meant that the
documentation did not reflect the actual parameter.
> Note: there are issues with the way that query parameters are put
> together in this sense, which is going to require substantially more
> work to resolve as well as discussion on how these options should be
> implemented, as what the Magento API requires may not be what is
> expected by a different server, and the nature of the input parameters
> is itself incorrect.
* [PHP] Bugfix - model_generic.mustache: missing setter for openAPINullabelsSetToNull (which is invoked in the property setters)
* [AUTOGENERATED] update samples
* [PHP] Added test for nullable fields
* [typescript-angular] Update api template to use HttpClient#request instead of its http-method-specific wrappers
* update expected output for integration tests
* regenerate samples
* fix(typescript-fetch): Handle cors errors.
If there is a communication error,
e.g. an OPTIONS request returns 404 not found,
then the whole request is cancelled and there is no
response object (it is undefined).
I observed the following error:
TypeError: Cannot read properties of undefined (reading 'status')
Basically response was undefined.
In order to circumvent this issue, we do a check
to make sure response is "truthy", which works
for objects.
With these code changes, it will throw a ResponseError,
which is what you would expect instead of a TypeError.
* regenerate typescript-fetch stuff
* retry code generation
Co-authored-by: Joe Heyming <jheyming@Roblox.com>
* [python-experimental] Enhance octet-stream deserialization
When the headers didn't provide the filename, use the url of response to
extract filename.
* [python-experimental] Remove todo comment.
* [python-experimental] Fix test code.
* Update samples
* [python-experimental] Refined the method and the test
+ Early return when the url is empty or `None`.
+ Removed unused f-string prefix.
* [python-experimental] Comapre url is None explicitly.
* Update samples.
* Further Elixir Client Improvements
Resolves#12731 and is the completion of the work that I started with
#12751.
The changes here are extensive and likely resolve an issue that I have
seen with the Ory SDK (ory/sdk#194). I have also been unable to run the
integration suite for Elixir as I am (trying) to run everything in
Docker (`./run-in-docker.sh`) as I *do not* have a suitable Java
development environment set up, and do not do enough Java work to really
justify it.
- Updated the README for Elixir projects. Aside from some improved
readability of the template by use of link references instead of
inline links, I have also fixed the examples:
- The `deps` example should have been putting a version constraint
related to `appVersion`.
- The `config` example should have been using `packageName` instead of
`appName`. This particular issue repeats.
- In all Elixir files:
- Changed the function `@docs` formatting:
- changed the ehading level for `Parameters` and `Returns` to h3
(`###` instead of `##`). This will make somewhat better looking
documentation that does not over-emphasize these details (which
are *not* documented in a normal Elixir way, but this is somewhat
to be expected with a code generator.) It may be desirable, after
testing, to change this to `h4` instead of `h3`.
- Put parameter names and most return types in in-line code blocks
(`` `hello` ``).
- Put return types, when there are multiple types, in a Markdown
list.
- Fixed a lot of the spacing. Most files will be *closer* to Elixir
standard formatting than they were. Because of the limitations of
Mustache, it is still recommended that people who generate Elixir
clients run `mix format` at least once on their codebase.
- `api.mustache`:
- Removed an awkward function pipeline call. If we specified at least
Elixir 1.12 (something that I do not recommend as we have recently
jumped from requiring Elixir 1.6 to Elixir 1.10), there is a better
way to specify this now with `Kernel.then/2`. In the meantime,
assigning the constructed request structure to a variable and then
making a separate pipeline for the request execution and handling
makes for *much* easier to read generated code.
- Fixed the extra space issue with `evaluate_response` call tuple
values; `{{=<% %>=}}` changes the tag types, so this change is
intentional.
- In `config.exs.mustache`, `runtime.exs.mustache`, `mix.exs.mustache`,
and `connection.ex.mustache`, use `packageName` instead of `appName`
for configuration specification. If `packageName` and `appName`
differed, we would end up with cases like ory/sdk#194.
- `connection.ex.mustache` has been almost entirely rewritten. The
changes started in order to eliminate a `@doc` compile-time warning,
but shifted to remove the old way of building Tesla client structs
with `use Tesla`. It works, but is no longer the recommended way of
building Tesla clients.
- The *recommended* way of building a Tesla Client would now be
`Tesla.client(Connection.middleware(), Connection.adapter())`.
- Exposed both `Connection.adapter/0` and `Connection.middleware/1`
for use. `Connection.middleware/1` has special handling for the
cases where OAuth2 or HTTP Basic Auth are defined in the
application, but do not currently handle any other auth methods.
- `deserializer.ex.mustache` has mostly been reformatted. There are
things that I do not like about it (I do not like pipelines with one
line), and I have expanded one function capture into an anonymous
function for readability.
- `request_builder.ex.mustache` has been updated with better
function and parameter descriptions and names. Please note that if
`request |> method(:delete) |> method(:post)` is supposed to produce
a `POST` operation, we will need to change from `Map.put_new/3` to
`Map.put/3`.
- Reordered `evaluate_response/2` so that it is the function documented,
and made `decode/2` and `response_mapping/3` private functions. As
far as I can tell, I have *not* changed the functionality.
* Address issues found in code review
- The example dependency code in the README had dropped the opening
brace for the tuple. This has been resolved.
- The default formatting of the API pipelines has been adjusted to
minimize possible changes from `mix format`.
* Update modules/openapi-generator/src/main/resources/elixir/api.mustache
Co-authored-by: Michael Ramstein <633688+mrmstn@users.noreply.github.com>
* Update modules/openapi-generator/src/main/resources/elixir/connection.ex.mustache
Co-authored-by: Michael Ramstein <633688+mrmstn@users.noreply.github.com>
* Update modules/openapi-generator/src/main/resources/elixir/connection.ex.mustache
Co-authored-by: Michael Ramstein <633688+mrmstn@users.noreply.github.com>
* Update templates based on review comments
Co-authored-by: Michael Ramstein <633688+mrmstn@users.noreply.github.com>
