Closed ro0NL closed 2 years ago
sounds useful to me. we can not simply add to the interface (BC break), but would need to have a separate interface (or extend the Formatter interface) and then have the calling code check the interface of the formatter to know whether to pass the request as well or not.
if we can avoid new symbols, that be nice.
Maybe we can take the @method
route on existing Formatter
, creating a new method: formatResponseForRequest
, sparing us a nullable arg also :)
then you would use method_exists to see if the new method is available? that could be a way to migrate in the next major version to have all formatters provide the new method (the default formatters can simply ignore the request when formatting the response). at the same time, we should deprecate formatResponse then, so that we can drop it in the next major.
yes, or manage the composer constraints as such. See also https://github.com/symfony/symfony-docs/issues/10504
at the same time, we should deprecate formatResponse then
there could still be value in having a method to format the response by itself, instead of forcing a request-response pair everywhere. Any implementor can forward formatResponseForRequest to formatResponse
having both adds a bit of complexity to formatters that do have different behaviour when the request is known. but then, they could be implemented as decorator on e.g. the simple formatter and just forward to that for this case. and while in the context of the logger plugin we will always have the request, there might be custom usage of the formatter where the request is not known.
do you want to do the PR to add the method with the annotation to the interface, and have our implementors implement it to simply forward to formatResponse?
See #146
Hi,
Would you consider passing the request to
formatResponse()
inFormatter
? Introducing "format response for request" effectively.We could use it to redact sensitve responses for certain URLs.
We could use it to hide response bodies for certain URLs that we don't care about.
The alternative route is to create a formatter per usecase, thus a plugin client per usecase ... which is really overhead :)
WDYT?