> I don't think it is at all natural to say "all middleware must be context free and middleware order never matters". That's simply unrealistic.
That's not what I'm saying. Of course middleware components are going to communicate facts about the state of the Request and Response - that's the whole point. Of course middleware order matters, as far as getting a meaningful result, I'm not trying to say otherwise. What I'm saying is, if you use the Request object as a transport mechanism for your _domain_ objects, stuffed into reserved attributes, you're first of all using the Request object as a service locator, which is bad practice. You're no longer communicating facts about the state of the Request or Response, you're just overloading the Request model as a means to avoid dealing with a dependency issue. Worse, you're hiding the fact that dependency exists, as is the general issue with service location. There are always going to be better, cleaner, simpler, more transparent patterns that don't hide your dependencies or solve the problem by using the Request model as a kind of "container" for your domain objects. IN MY OPINION, attributes in the Request object are widely abused as a general solution to all sorts of dependency issues, when, really, they probably ought not to be used for much else other than an additional source of parameters. Per the PSR-7 definition, attributes hold "parameters derived from the request" - I find that stuffing your domain objects in there under reserved keys is a bit of a stretch, even if your domain objects were somehow "derived from the request", with examples given such as "the results of path match operations; the results of decrypting cookies; the results of deserializing non-form-encoded message bodies; etc.", I think it's quite a long reach. Bottom line, if it doesn't really function like middleware, why did you implement it as middleware? Wrong abstraction for the job. On Wed, May 10, 2017 at 11:36 PM, Woody Gilk <[email protected]> wrote: > On Wed, May 10, 2017 at 1:54 PM, Rasmus Schultz <[email protected]> > wrote: > >> In my opinion, if a middleware component doesn't work when taken out of >> context from other middleware, or is dependent on related middleware and >> execution order etc., it's no longer middleware, strictly speaking - at >> that point, you're overloading the middleware mechanism with >> responsibilities that don't belong to that domain and don't naturally fit >> there. > > > That's purely an opinion and I definitely don't agree about the execution > order. Would this make sense: > > middleware = [ > ActionHandler, > ClientIp, > Authorization, > ] > > Of course not! Some middleware will always need to be early or late in > processing. Authentication and authorization will need to be early, and > action handling will need to be late. I don't think it is at all natural to > say "all middleware must be context free and middleware order never > matters". That's simply unrealistic. > > -- > Woody Gilk > http://about.me/shadowhand > > -- > You received this message because you are subscribed to a topic in the > Google Groups "PHP Framework Interoperability Group" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/php-fig/B3jtdJA7-6w/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/php-fig/CAGOJM6%2BKW4nFeyMb07%3DGvY0C9nj9ChtrCe8cHLAiJJs% > 3DPwjd-w%40mail.gmail.com > <https://groups.google.com/d/msgid/php-fig/CAGOJM6%2BKW4nFeyMb07%3DGvY0C9nj9ChtrCe8cHLAiJJs%3DPwjd-w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADqTB_jwot32byz9Ac5M3ipO1OLPzutMRGGTOOmJXTC8iUFfaQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
