You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As touched on briefly in #134, if a parameter has a filter defined, Guzzle Services applies that filter at the following stages:
Before validation, in \GuzzleHttp\Command\Guzzle\Handler\ValidatedDescriptionHandler::__invoke().
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.
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.
The text was updated successfully, but these errors were encountered:
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.
…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
As touched on briefly in #134, if a parameter has a
filter
defined, Guzzle Services applies that filter at the following stages:\GuzzleHttp\Command\Guzzle\Handler\ValidatedDescriptionHandler::__invoke()
.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.
This leads to the following awkwardness:
json_encode()
is being used to control the way a parameter is being written-out to the wire: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.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.
The text was updated successfully, but these errors were encountered: