What is the difference between the global definitions section and the components section in Swagger 2.0?
I came across a Swagger definition YAML file which is marked as swagger: '2.0'.
It has one section called definitions just below parameters. This is similar to what is described in
https://swagger.io/docs/specification/2-0/basic-structure/
under the "Input and Output Models" section.
Also further down the file, it has the components section with the schemas section underneath it. That is similar to what is described in
https://swagger.io/docs/specification/components/
This looks like OAS3.
However, this specific YAML file has both sections. I am not exactly sure whether definitions is for Swagger 2.0 and components and schemas is in OAS 3.0. Is that so?
Can both definitions and components be used in the same YAML file of type swagger: '2.0' or should we stick to either definitions or components?
# definitions section looks like this
definitions:
User:
properties:
id:
type: integer
name:
type: string
# Both properties are required
required:
- id
- name
# components section looks like this
components:
schemas:
Address:
type: object
properties:
line1:
type: string
city:
type: string
I am not exactly sure whether definitions is for Swagger 2.0 and components and schemas is in OAS 3.0. Is that so?
Yes, exactly.
The definitions section is used in OpenAPI 2.0 files (swagger: '2.0').
The components section is used in OpenAPI 3.x (openapi: 3.x.x).
Can both definitions and components be used in the same YAML file of type swagger: '2.0' or should we stick to either definitions or components?
No, you can't mix 2.0 and 3.x syntax in the same file. If your file is swagger: '2.0' you must use 2.0 syntax. If it's openapi: 3.0.0 you must use 3.0 syntax.
Related
Let's say I have this basic app:
from dataclasses import dataclass
import hydra
from hydra.core.config_store import ConfigStore
#dataclass
class MyAppConfig:
req_int: int
opt_str: str = "Default String"
opt_float: float = 3.14
cs = ConfigStore.instance()
# Registering the Config class with the name 'config'.
cs.store(name="base_config", node=MyAppConfig)
#hydra.main(version_base=None, config_name="base_config", config_path="conf")
def my_app(cfg: MyAppConfig) -> None:
print(cfg)
if __name__ == "__main__":
my_app()
Is it possible for the user to be able to call my app like this:
python my_app.py req_int=42 --config="~/path/to/user-defined-config.yaml"
And user-defined-config.yaml would contain only this:
opt_str: User Config String
The output should look like this:
{'req_int': 42, 'opt_str': 'User Config String', 'opt_float': 3.14, 'config': 'hydra-user-conf'}
The closest I got to that is:
user-defined-config.yaml
defaults:
- base_config
- _self_
opt_str: User Config String
And the invocation:
python hydra/app.py req_int=42 --config-path='~/path/to' --config-name="hydra-user-conf"
But this way the user (who I don't want to require to be familiar with hydra) has to specify the path to their config file via two cli arguments and also include the defaults section in their config, which would be redundant boilerplate to them if they have to always include it in all of their configuration files.
Is this the closest I can get with hydra to the desired interface?
One thing you can do is to pre-configure the config searchpath in the primary config. Adding something like ~/.my_app/ to your config searchpath (thus potentially eliminating the need for --config-path|-cp.
In yaml it would look like:
hydra:
searchpath:
- file://${oc.env:HOME}/.my_app
Another thing to consider is having the app generating an initial config for the user on demand. I took this approach with Configen.
In general, the current patterns are not amazing and maybe there is room for some improvements in Hydra to make this more ergonomic (You can open a discussion about it).
I'm trying to figure out with Sylius routing, based on Symfony framework. I found that code
sylius_admin_channel:
resource: |
alias: sylius.channel
section: admin
templates: "#SyliusAdmin\\Crud"
except: ['show']
redirect: update
grid: sylius_admin_channel
permission: true
vars:
all:
subheader: sylius.ui.configure_channels_available_in_your_store
templates:
form: "#SyliusAdmin/Channel/_form.html.twig"
index:
icon: share alternate
type: sylius.resource
But I could not find any information what is it | for resource. Any help?
Thanks.
It's the YAML syntax for a multi-line string (that preserves newlines).
So sylius_admin_channel is a mapping that has two keys (resource and type) whose values are both string types.
It can be confusing to see in this instance because the string happens to also be valid YAML. I edited your question to include syntax highlighting for YAML which makes this a little more obvious, visually.
If I didn't know any better, I would have guessed that the | is there in error and resource should actually have a mapping type for its value. If you remove the |, then same symbols that were within that string still produce valid YAML for the whole file, but the value of resource would be a mapping, rather than a string.
Notice the difference in syntax highlighting, compared to the yaml in the question with the | removed:
sylius_admin_channel:
resource:
alias: sylius.channel
section: admin
templates: "#SyliusAdmin\\Crud"
except: ['show']
redirect: update
grid: sylius_admin_channel
permission: true
vars:
all:
subheader: sylius.ui.configure_channels_available_in_your_store
templates:
form: "#SyliusAdmin/Channel/_form.html.twig"
index:
icon: share alternate
type: sylius.resource
I have an Open API 3 spec yaml file that has some x- prefixed properties. I'm trying to generate an Angular Typescript SDK using openapi-generator-cli. However when I reference the property in the template mustache, the x-prefixed property is always blank.
Example endpoint from the yaml (irrelevant stuff omitted):
/about:
get:
summary: Information about this API
x-foo: getAbout
How I'm using it in the Mustache template (irrelevant stuff omitted):
{{#operation}}
public {{x-foo}}({{#allParams}}{{paramName}}{{#hasMore}}, {{/hasMore}}{{/allParams}})
(Basically I'm trying to use the x-foo parameter as the method name in the SDK that is being generated.)
The generated SDK, however, replaces {{x-foo}} with blank:
public ()
This is how I'm invoking the generator (without the newlines):
openapi-generator generate
--generator-name typescript-angular
--template-dir ./path/to/templates
--input-spec ./path/to/api.yml
--output ./output
--config ./path/to/config.json
How can I reference a vendor extension / x-prefixed Open API 3 property from within openapi-generator template?
Vendor Extensions are made available inside of a vendorExtensions parent property, not directly.
So to access an x-foo property from the mustache template, the example above would be:
{{#operation}}
public {{vendorExtensions.x-foo}}({{#allParams}}{{paramName}}{{#hasMore}}, {{/hasMore}}{{/allParams}})
To see the object that you're working against (eg. the parsed version of the api spec yml or json), run the generate command with the -v flag. One of the many things that will be printed out is the parsed spec.
I was wondering if it is possible with Symfony 3.5 to use multiple translation files for a single language when using yml files.
Currently I have something like this:
AppBundle/Resources/translations/messages.en.yml
AppBundle/Resources/translations/messages.de.yml
which contains all my translations in either language. However I was wondering if it was possible to change this to the following structure:
AppBundle/Resources/translations/en/products.yml
AppBundle/Resources/translations/en/invoices.yml
AppBundle/Resources/translations/de/products.yml
AppBundle/Resources/translations/de/invoices.yml
I have been looking but I have been unable to find some kind of solution for this. I got it working for splitting up my routes.
AppBundle/Resources/config/routing.yml
appbundle_routes:
resource: '#AppBundle/Resources/config/routing'
type: directory
Inside that folder I got all my routes split like:
AppBundle/Resources/config/routing/products.yml
AppBundle/Resources/config/routing/users.yml
AppBundle/Resources/config/routing/invoices.yml
I was wondering if it was possible to achieve the same thing with translations?
Symfony's Translator requires files to by named in format domain.locale.loader. In case you have messages.en.yml:
messages is the default name of domain, you can also specify eg. invoices
en is the locale
yml is specifying YAML loader will be used
So your proposed use is not possible to achieve with standard set of configs and functionality. However, you can split your translations to different domain files. So paths would be:
AppBundle/Resources/translations/products.en.yml
AppBundle/Resources/translations/invoices.en.yml
And when you are using translator you specify the domain in which the translation should be looked for:
$translator->trans('translated.key', [], 'invoices');
Or in Twig:
{{ 'translated.key'|trans({},'invoices') }}
How can I add a file in /config/validation.yaml as a mapping validation in order to avoid using annotations in my DTOs?
Is quite simple.
Just add in validator.yaml file the following:
framework:
validation:
email_validation_mode: html5
mapping:
paths:
- '%kernel.project_dir%/src/<path to validation file>'