change code access level

[NaccOll]

Is your feature request related to a problem? Please describe.

I found some issues when I migrated from springfox to springdoc. According to the documentation, I just need to do the equivalent replacement of the annotation and I'll be able to get the migration done, but the fact slaps me.

1. @ParameterObject must be added when using objects as query parameters.
2. no solution about using object when submitting form data. Must use multiple property with @RequestPart
3. no solution about showing field description with @Schema in object when I use object as query param. Must use @paramter with field.

Describe the solution you'd like

I reimplemented MethodParameter and org.springdoc.core.AbstractRequestService to solve the problem mentioned in the first part. However, this method is very troublesome,

Describe alternatives you've considered

the access level of the code causes me to copy a lot of unnecessary code. I hope to change the access level of the code, so that I can accomplish my goal by inheriting and rewriting a few core methods.

Additional context

springfox
repo: https://github.com/NaccOll/springdoc-issue-demo/tree/springfox

springdoc
repo: https://github.com/NaccOll/springdoc-issue-demo/tree/springdoc

springdoc-fix
repo: repo: https://github.com/NaccOll/springdoc-issue-demo/tree/springdoc-fix

springdoc-custom
repo: repo: https://github.com/NaccOll/springdoc-issue-demo/tree/springdoc-custom

[bnasslahsen]

@NaccOll,

Thank you for your efforts.
Are you willing to propose a PR ?

[NaccOll]

@NaccOll,

Thank you for your efforts. Are you willing to propose a PR ?

ok

[bnasslahsen]

@NaccOll,

The following test shows that with the latest SNAPSHOT, you will able to reach the same result as in springdoc-custom branch.

https://github.com/springdoc/springdoc-openapi/tree/master/springdoc-openapi-webmvc-core/src/test/java/test/org/springdoc/api/v30/app189

Do not hesitate to provide your feedback and any enhancements you feel useful for the adoption of the library.

[NaccOll]

@bnasslahsen
Is there any plan to remove @ParameterObject. Or provide a method for overriding org.springdoc.core.DelegatingMethodParameter#customize

[bnasslahsen]

@NaccOll,

Why do you want remove @ParameterObject ?

[NaccOll]

@bnasslahsen
In the default behavior of spring boot, objects are automatically flattened. You can see this phenomenon in the example repository of this issue. This is also to reduce the migration cost brought by using springdoc
https://github.com/NaccOll/springdoc-issue-demo/blob/springfox/src/main/java/com/example/demo/api/ArticleApi.java
https://github.com/NaccOll/springdoc-issue-demo/blob/springdoc-custom/src/main/java/com/example/demo/api/ArticleApi.java

[bnasslahsen]

@NaccOll,

We are not copying springfox behaviors.
I would agree to make the developer experience easier, but this should not bring any regressions for exisisting projects as well.

We have also to support projects that do not want a flattened representation of their objects...
And in addition, how do answer to a project who wants for some controllers a flattened representation and for others no flattened representation...

[NaccOll]

@bnasslahsen

1. I don't think it's a springfox behavior, it's a spring mvc default behavior. When I pass a complex object as a parameter in a controller method without using any other annotation, spring boot automatically flattens it, turning the object property into query parameters or form data. So I don't understand what projects that do not want a flattened representation of their objects. Webflux? Or something else?
2. Based on the first point, the migration I am talking about is not necessarily from springfox, it may also be a project that wants to integrate external documents back into the project. It takes a lot of time for them to add @ParameterObject to adapt to the real api handler.
3. Although I don't understand what kind of scenario "a project who wants for some controllers a flattened representation and for others no flattened representation" is, I dealt with it in my pr. The answer is configuration, you can set a switch , the default is off, to avoid the incompatibility of the old version user. See Here

[bnasslahsen]

For the first point, can you please add the source code that shows it?
Making flattened representation default behaviour is in my opinion risky and might cause regression as not enough tested.
For the first and third point, there are so many requests from people that we need to be flexible.(This is just my point of view)
For the third point, there are so many requests from people that we need to be flexible.

Anyway, if you are confident in a change with this property defaultFlatQueryObject based on our discussion, you can add a PR just for it.
For the visibility, no problem to change it, but we can add it in different PR so we can have better traceability.

[NaccOll]

@bnasslahsen
I still use this example repository in the issue.

    @GetMapping("query")
    public List<ArticleDto> query(ArticleQueryCondition condition) {
        return new LinkedList<>();
    }

    @PostMapping(value = "create", consumes = MediaType.MULTIPART_FORM_DATA_VALUE)
    public ArticleDto create(ArticleDto dto, @RequestPart MultipartFile file) {
        return new ArticleDto();
    }

public class ArticleQueryCondition {
    private String title;

    public String getTitle() {
        return title;
    }

    public void setTitle(String title) {
        this.title = title;
    }
}

public class ArticleDto {
    private String title;

    private String content;

    public String getTitle() {
        return title;
    }

    public void setTitle(String title) {
        this.title = title;
    }

    public String getContent() {
        return content;
    }

    public void setContent(String content) {
        this.content = content;
    }
}

when I access /query, the parameter of the method is ArticleQueryCondition, SpringBoot automatically flattens it, so the query parameter I should use is title, not condition. Http Request as follow:

GET /query?title=1 HTTP/1.1
Host: localhost:8080

when I access /create, the parameter of the method is ArticleDto, SpringBoot automatically flattens it, so the form data I should use is ['title','content'], not dto. Http Request as follow:

POST /create HTTP/1.1
Host: localhost:8080
Content-Length: 380
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="title"

test title
----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="content"

test content
----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; filename="/D:/Desktop/test.txt"
Content-Type: text/plain

(data)
----WebKitFormBoundary7MA4YWxkTrZu0gW

Of course, the case of submitting dto, but the developer will add @RequestPart annotation to the parameter.

@PostMapping(value = "create", consumes = MediaType.MULTIPART_FORM_DATA_VALUE)
public ArticleDto create(@RequestPart ArticleDto dto, @RequestPart MultipartFile file) {
    return new ArticleDto();
}

So I think flattening is a default behavior of Spring Mvc.

I will add pr about the default flat configuration. However, I have doubts about the code style of this repository. I am currently using spring-javaformat to standardize my code, which does not match this repository. What should I do? Manually adjusting spaces and line lengths is a hassle.

[bnasslahsen]

We Use the spring formatter.
The détails are available in the contribution guide https://github.com/springdoc/springdoc-openapi/blob/master/CONTRIBUTING.adoc