You are not logged in.
Pages: 1
I ran into an Issue with the Swagger/OpenAPI Client Generator mopenapi from current Mormot 2.4 release.
It redefines typical FPC labels without hassitation...
In my case it redefined TLabel, wich is obviously a bad idea ![]()
There should be some mechanism / prefix to make sure typical fpc clases (label, edit etc.) are not overwritten.
I dont know if Im allowed to publish the full json, but this should be the critical part:
"Label": {
"type": "object",
"description": "Label that is used for entities like tags.",
"properties": {
"createdAt": {
"type": "string",
"format": "date-time",
"description": "The date when the entity was created"
},
"createdBy": {
"$ref": "#/components/schemas/UserReference"
},
"hidden": {
"type": "boolean",
"description": "Whether the label is hidden or not"
},
"id": {
"type": "integer",
"format": "int32",
"description": "Id of the entity",
"minimum": 0
},
"name": {
"type": "string",
"description": "Name of the entity"
},
"privateLabel": {
"type": "boolean",
"description": "Whether the label is private or not"
}
},
"readOnly": true
}Thanks and best regards
Dirk
Offline
What about adding the unit names in the beginning as prefix of the type name?
This is how usually how type names collision is resolved in practice.
If we would try to detect some forbidden components names, we would need to be able to detect all components names, not only TLabel and TEdit.
So a huge list of forbidden identifiers is no option I guess.
So perhaps TOpenApiParser.DtoTypePrefix would help.
A prefix with T*SwaggerName could make them genuine - and more easy to spot.
Please try https://github.com/synopse/mORMot2/commit/f2d2974f
Offline
Thanks for having a look into it. As it is a "side project" I need some days time until I can have a look back into it ![]()
I'm not 100% sure. But I think there is an issue. I wrote a small sample application that Gets and Puts a "Trackeritem". With the original mormot 2.4 release its working.
With the commit mentioned i added oa.DtoTypePrefix:='CodeBeamer'; to mopenapi tool.
generated Files look good.
I just exchanged the generated Files and added the "CodeBeamer" Prefix to the types, after that, the
GET REST command is working but for PUT command I now get: {"message": "JSON parse error: Class cannot be resolved by type: ","resourceUri":"/items3956"} during the runtime when I call the generated put function.
I know this looks like a "user issue" not using the REST Api correct, but as I did not really change s.th. in the code and it worked before...
Please let me know when it makes no sense to talk about it wihtout the actual source code. I'll check whats possible then. I dont know if they allow me to put the openapi spec public, as i needed to login to get it.
Thanks so much.
Last edited by DirkH (Yesterday 06:48:00)
Offline
I found the issue but not a clean solution.
I need client option "jcoPayloadWithoutVoid". Which I set earlier in the created TCodeBeamerClient.create constructor. Of cause this one was overwritten by MOpenApi when regenerating it. Maybe thats why someone wrote "DO NOT MODIFY BY HAND" in the file ![]()
But I can not see a way how to do it without modifying xx.client.pas?
I did not found an option in MOpenApi to generate the flag.
I think I cannot hand it over from my Main Program because the codebeamer.client.pas hardcodes the options to:
constructor TCodeBeamerClient.Create(const aClient: IJsonClient);
begin
fClient := aClient;
fClient.Options := [jcoParseTolerant, jcoHttpErrorRaise];
fClient.UrlEncoder :=
[ueEncodeNames, ueSkipVoidString, ueSkipVoidValue, ueStarNameIsCsv];
end; Offline
Pages: 1