ebda02438e
* Split the action into two constructs: `Input` and `ExecutableInput`. The former holds all the input configuration, the latter can execute the input based on that configuration (an executable input holds an input) - This the code clearer to understand and maintain. - This also enabled to pull some common implementation code into the `ExecutableInput` and by that reduce the implementation details of each executable to the minimum required. * Also, extracted the `Input.Parser` to its own top level class, and renamed it to - `InputFactory`. The main thing that the factory does is: 1) delegate to the parsing to the `Input` class, 2) construct & wire up the `ExecutableInput`. * With the introduction of `Input`, we no longer need the `SourceBuilder` for inputs. Instead, we have an `Input.Builder` that help you build an input. This is much more intuitive from the client perspective. * Changed the `request` xcontent field in the http input result to `sent_request` for clarity * Changed the `request` xcontent field in the search input result to `executed_request` for clarity Original commit: elastic/x-pack-elasticsearch@63b93f9c7b |
||
|---|---|---|
| .. | ||
| 10_basic.yaml | ||