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

Feature Request - Ability to Bind Parameter Filters to Specific Request Stages #169

Open
GuyPaddock opened this issue Aug 20, 2019 · 0 comments

Comments

@GuyPaddock
Copy link

GuyPaddock commented Aug 20, 2019

As touched on briefly in #134, if a parameter has a filter defined, Guzzle Services applies that filter at the following stages:

  1. Before validation, in \GuzzleHttp\Command\Guzzle\Handler\ValidatedDescriptionHandler::__invoke().
  2. Before writing the value out to the wire in a request, in:
    a. GuzzleHttp\Command\Guzzle\RequestLocation\AbstractLocation::prepareValue()
    b. GuzzleHttp\Command\Guzzle\RequestLocation\AbstractLocation::resolveRecursively()
    c. GuzzleHttp\Command\Guzzle\Serializer
    d. ...and several different request location handlers.
  3. After reading a value in from a response on the wire, in several response location handlers.

This leads to the following awkwardness:

  • If a filter like json_encode() is being used to control the way a parameter is being written-out to the wire:
    • It inadvertently has an effect on the format of the parameter on its way through validation. So, for example, a value that should come in as an array has to be declared as a string to prevent validation from erroring-out on the JSON string. There's no way to make these types of filters happen only after validation.
    • It gets applied twice (in both 1 and 2 above), so instead of sending a JSON string, it sends a JSON-escaped JSON string (i.e. the value gets double-encoded, as a quoted JavaScript string instead of JSON).
  • Default values only run through one filter (2), which leads to different results than if you passed-in a value equal to the default. IMHO, the default value should be run through validation the same way as passed-in values, but that's a separate issue.
  • Filter functions/methods don't really have a good way to differentiate between filtering that happens to values going out in a request and values coming in from a response. This is likely not a huge issue since different parameters are used for request and response data, AFAIK.

Ideally, there'd be a way to "bind" a filter to a particular stage of the process, so that it's only invoked when desired.

GuyPaddock pushed a commit to GuyPaddock/guzzle-services that referenced this issue Aug 21, 2019
…ssing

Makes it possible for a filter definition to include a new `stage` key
that can be set to `before_validation`, `after_validation`,
`request_wire`, or `response_wire`; which binds the filter to fire off
either before validation (the default), after validation, before being
written to the wire in a request, or after being read from the wire from
a response, respectively.

Still needs tests.
GuyPaddock pushed a commit to GuyPaddock/guzzle-services that referenced this issue Aug 21, 2019
…ssing

Makes it possible for a filter definition to include a new `stage` key
that can be set to `before_validation`, `after_validation`,
`request_wire`, or `response_wire`; which binds the filter to fire off
either before validation (the default), after validation, before being
written to the wire in a request, or after being read from the wire from
a response, respectively.

Still needs tests.
GuyPaddock pushed a commit to GuyPaddock/guzzle-services that referenced this issue Aug 21, 2019
- Cleans-up logic that was working around `$this->filters` being empty.
- Fixes method visibility for `expandFilterArgs()`.
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

Successfully merging a pull request may close this issue.

1 participant