Added strategies to the BodyParamsMiddleware

[weierophinney]

This patch builds on the one in #3, moving the act of parsing a Content-Type as well as parsing the request body to strategies, which implement Zend\Expressive\BodyParams\StrategyInterface. These define two methods:

• match($contentType), which should accept a Content-Type header value, and return a boolean value indicating whether or not the strategy matches.
• parse(ServerRequestInterface $request), which should accept the request instance, parse its raw body, and return a new request instance with the results of parsing injected as the parsed body.

The form and json matching/parsing were rewritten as strategies, and added as default strategies to the middleware. Custom strategies can be written and then attached using addStrategy().

[weierophinney]

@michaelmoussa This is what I meant by strategies. 😄

[michaelmoussa]

@weierophinney This makes a lot of sense and really eases extensibility! I wonder if there might be other common types of middleware in which strategies like this would be useful?

I can't think of any non-trivial examples off the top of my head, and I really like how it's done in this PR, but I can't help but wonder if there's a sensible, meaningful way to have a more generic StrategyInterface and some corresponding more generic interface that a middleware could implement to indicate that it supports the use of strategies as a way of encouraging consistency among other similar helper middlewares.

Maybe something to think about for a later date, but what's here now looks good and definitely satisfies my original need that led me to submit the PR in the first place.

👍

[snapshotpl]

Nice one. Can someone explain me what FormUrlEncodedStrategy is doing?

[weierophinney]

@snapshotpl It's in there to match as early as possible, and return the request verbatim.

The reason: we don't want to loop through all strategies if we don't need to, and that's likely the most common match. The typical PSR-7 implementation will have populated the body parameters from $_POST in that case, so there's nothing left to do. By having it as the first in the list of strategies, we get a small performance optimization, as there will be only the one match performed (vs. attempting to match all strategies).

[snapshotpl]

@weierophinney thanks for clear explanation

[weierophinney]

I can't help but wonder if there's a sensible, meaningful way to have a more generic StrategyInterface and some corresponding more generic interface that a middleware could implement to indicate that it supports the use of strategies as a way of encouraging consistency among other similar helper middlewares.

@michaelmoussa — while there's a part of me that likes this idea, there's another part that doesn't. Strategy patterns are usually highly specific to a given domain. As an example, the approach in this patch requires:

• matching the incoming content-type header, and
• parsing the request body and returning a new request with the parsed body parameters, and
• ensuring that the above two occur in exactly that sequence.

As such, a generic approach likely wouldn't work; we'd still need to typehint or perform type checks internally on the more specific interface that provides those capabilities.

What we can do is start looking at new middleware that crops up that could benefit from a similar approach, and make sure that the general approach of attaching strategies is the same. In other words, ensure that these each use addStrategy() and clearStrategies() in their implementations, to ensure consistency of use across different middlewares using the approach.