Please add a section about .gateway() to the online DSL Documentation

[swiss-chris]

Expected Behavior

https://docs.spring.io/spring-integration/reference/html/dsl.html#java-dsl-basics mentions .gateway() and possibly https://docs.spring.io/spring-integration/reference/html/dsl.html also has its own section about Gateways, e.g. https://docs.spring.io/spring-integration/reference/html/dsl.html#java-dsl-gateways

Current Behavior

There is no mention of .gateway() and no use of it in the spring-integration-saples code either. It's easy to completely miss that this endpoint exists in the DSL

Context

On Stackoverflow, @artembilan suggested I post this GH request.
https://stackoverflow.com/questions/68400511/spring-integration-dsl-how-to-refactor-into-subflows#comment120898078_68402954

How has this issue affected you?

It took me way to long to realize that Spring Integration DSL hat a .gateway() method available when .gateway() was exactly what I needed.

[swiss-chris]

@artembilan @garyrussell will you add a mention of .gateway() to the bullet list under https://docs.spring.io/spring-integration/reference/html/dsl.html#java-dsl-basics as well ?
(inside the same dsl.adoc file, but earlier in the document where you list all the endpoints)

[artembilan]

Probably no, because this one is some kind of handle() (Service Activator) and we mention over there just some general only.
As you see there is also something like enrichHeaders or scatterGather.
The point of those bullets just to give you a general idea of methods you can see in the IntegrationFlowDefinition.
Since we have there at about 100 methods it would be too excessive to list all of them in the doc.
It is much better to open JavaDocs of that class and follow the list of existing methods.
Another way is to come over the rest of Spring Integration documentation and make yourself familiar with all possible EIP implementation first of all and then go to IntegrationFlowDefinition trying to search for a respective method support.
The Java DSL is just a tool to simplify target developer experience, but it must not be treated as a source of truth for EIP implementations. It is really done in their individual classes and packages.