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
- Extend the logic of an existing renderer
- Build your own model renderer
- Create your own models from the ground up, instead of a supported input
- Adapting input and outputs
- Add logging to library
- Change the generated indentation type and size
- Change the naming format for properties
- Change the naming format for data models
TODO
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.
Supported by:
- Java
- TypeScript
- C#
- Go
- JavaScript
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.
TODO
TODO
TODO
TODO
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.
TODO
TODO