Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ordering of class definitions #15

Open
thetoolwiz opened this issue Feb 7, 2020 · 5 comments
Open

ordering of class definitions #15

thetoolwiz opened this issue Feb 7, 2020 · 5 comments

Comments

@thetoolwiz
Copy link

thetoolwiz commented Feb 7, 2020

Our Swagger spec is pretty large and the code generated by GenerateUnitFileForMVCFramework emits some classes in the wrong order after they've been sorted.

Actually, there's a bug in the sort routine:

TDelphiUnit.SortTypeDefinitions looks for 'TMyMVCController' while it should look for 'TMyMVCControllerClient'

Anyway, there's a comment there about this topic, and my swagger spec has 10 classes declared out-of-order that need to be moved manually.

@thetoolwiz
Copy link
Author

If I comment out the sorting, it seems to work properly.

@geoffsmith82
Copy link
Contributor

I've been working on this and should have an update shortly to handle this issue. Commenting out the sorting works because the swagger file has been created with all the definitions in the right order.

@marcelojaloto
Copy link
Owner

@geoffsmith82
have you made any progress?

@geoffsmith82
Copy link
Contributor

Have a look at

https://github.com/geoffsmith82/SwagDoc/tree/Dependency-Ordering

The ordering works, but I messed up some of the parameter and object generation. My understanding of the problem has improved....
The types are defined in 3 places

  • in the definition section
  • inline in the request/response.
  • as a sub-object of the inline request/response.

The definition section is easy to create the Delphi type information for. The 2nd 2 are a bit more complicated. One thing you need to do is work out a suitable name that is unique for that request - it can't be the same as what is in the definition section or in any other request/response object.

This can partly be solved by using TInline as a prefix for the generated objects. This doesn't solve the problem for where an object name is duplicated between multiple calls in the API.

This loading of the Type information is currently not integrated into SwagDoc properly yet... I am decoding it in the demo program. This would be best loaded/saved in the actual SwagDoc API using the json.schema objects.

@marcelojaloto
Copy link
Owner

@geoffsmith82 did you manage to finish this? I managed to generate a PR or we can close this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants