Hello,
I have another question regarding generating open api from diagram.
While regenerating document it has different order of components from time to time so keeping up with changes done to exported yaml is messy…
I want to add examples to attributes, but its not possible afaik 
, there is initial value, but no example. So I’m modeling, and generating api and in the yaml adding example data to attributes. But… sometimes I add new diagram, and generate new yaml, aand, it has different order! Is there some possibility to sort it, or I don’t know. somehow add checkbox for sorting at least components? Or I don’t know. I’d like to keep using it, but these missing features keep bugging me slightly 
Are there some tools you use to do this kind of modeling more seamless?
Hello
I’m full agree
Regarding data sorting in API documentation, it’s ok for me
Regarding the need to include examples in the description, it’s very important to me.
In addition, with the model-type “instance” of the diagram object, it seems really simple to implement this comportement ?
Could you tell me if you can add this behavior in future version
Thanks in advance
Json attendu
[
{
“attribute1”: “value1.1”,
“attribute2”: “value1.2”,
“attribute3”: “value1.3”
}
,
{
“attribute1”: “value2.1”,
“attribute2”: “value2.2”,
“attribute3”: “value2.3”
}
]
Thank you for your message. Our engineers tested the Open API generation but cannot repeat the “different order” issue you experienced. Would you please send me your project file for testing? You can send it to support-team@visual-paradigm.com for diagnosis. Thanks and look forward to hearing from you.
About the example in generated Open API the difficulties are not on adding a property somewhere in meta model, provide UI for user to define it and output it back to Open API. The difficulty is how to make it become make sense across the entire application. The example should be bind to the REST request instead of the classes. Since our product is not just for model and generate Open API, the classes can be use by both REST request and general models, or use by multiple REST requests. In this case the “example property” will not able to cover all situation since each REST request may require different examples on the same class, or it simply not make sense to show when the class is not related to any REST request. Please understand I don’t mean we refuse to support this. We are willing to have this if we can found an elegant solution.
