This document contains many of the advanced use-cases that you may stumble upon when pushing the limits of Modelina.
- Generate each model in the same file
- Generate models to separate files
- Include a custom function in the data model
- Use the models for data transfer
- Adapting input and outputs
- Add logging to library
- Change the generated indentation type and size
- Change the type mapping
- Changing the constrain rules
- Customizing the interpreter options
This example shows us how to generate each model in the same file
Check out this example out for a live demonstration.
The standard generator only allows you to generate the raw models which you can implement your own logic for generating the models to separate files. We have however create simple wrapper generators to use.
The reason for splitting the functionality is because in certain environments (like pure front-end application), generating to a file is not needed.
The file generators all follow the same pattern regardless of output language, which is the following format - <language>FileGenerator.
It is not supported in browsers.
Check out this example out for a live demonstration.
Sometimes you want to include custom functionality into the generated models, this can be done through a custom preset using the hook additionalContent.
Check out this example out for a live demonstration.
One of the primary use-cases for the generated models, is to serialize and deserilize it to for example JSON, XML or binary. Each generator can have multiple ways to achieve this, and even support multiple libraries. This is achieved through presets, you can find them here for each output:
Sometimes you simply cannot make two things work together as you wished, maybe the input does not support it, or Modelina natively doesn't. However, because of the nature with presets, we can make it work anyway.
With great customization comes a great responsibility. Always make sure to raise your issue before trying workarounds, maybe you are not alone in the problem, and it should be natively supported, so please make your due diligence before venturing into this 🙏 And always feel free to reach out on the AsyncAPI slack channel if you want some quicker feedback!
Check out this example for a demonstration of how to adapt the input and out to a specific use-case.
When you generate models, by default, nothing is logged to the console or elsewhere.
If you want to integrate a logging implementation specific to your needs, this library allows you to implement a detached logging module.
The library uses 4 different logging levels:
debug: for specific details only relevant to debugginginfo: for general information relevant to the userwarn: for warnings a user may need if the output is not as expectederror: for errors that occur in the library
Check out this example out for a live demonstration.
In some scenarios, depending on how you stitch them together, you might need to change the indentation type or size and both of these cases are fully supported.
Check out this example out for a live demonstration.
Sometimes, the default type mapping simply dont use the types you expected, or fit into your use-case. Thats why the entire mapping from MetaModels to constrained types can be altered.
Check out this example out for a live demonstration.
When moving from a MetaModel to a ConstrainedMetaModel it means we bind the input to a specific output. That output has specific constraints that the input MUST adhere to, read more about this here.
There can be multiple reasons why you want to change the default constrain rules, and therefore you can form them to your needs.
Check out this example out for a live demonstration for how to overwrite the default constraints.
Check out this example out for a live demonstration for how to overwrite the naming formatting for models.
According to JSON schema draft 7, if additionalProperties or additionalItems are omitted, their default value is true. The Interpreter honors this behavior, however this creates more loose models that might not be the intention for the developer.
We suggest not using this option if it can be avoided, as it limits your generated models to include any additional properties, and would simply be ignored. Instead adapt your schemas to be more strict by setting these keywords to false. This option should really only be used when you have no control over your input and the output is unintended.
To set the interpreter up to ignore the default behavior, you can further restrict your models with the following options:
ignoreAdditionalProperties- if set, it ensures thatadditionalPropertiesby default is ignored.ignoreAdditionalItems- if set, it ensures thatadditionalItemsby default is ignored.
Check out this example out for a live demonstration for how to customize the behavior of additionalProperties.