Last week\u2019s announcement of Radar, an implementation of Action-Domain-Responder using PSR-7, was a resounding success. The feedback has been mostly positive, with some confusion and misunderstanding, and with one particular question being raised more than once.
\nThis Reddit thread is typical of the various questions and comments I\u2019ve received so far:
\n\n\n[\u201cADR\u201d is just] the hipster slang for \u2018c\u2019, \u2018m\u2019 and \u2018v\u2019.
\n
In other words, \u201cWhy ADR in the first place, and not just MVC?\u201d This is answered by the ADR white paper, and again by some commentary here. In short, ADR is a refinement of \u201cweb\u201d MVC to more accurately describe how we actually work in a request/response environment. The renaming of the components is intended to break the association with \u201creal\u201d MVC. (Special thanks to \u201clordofworms\u201d for his patient and civil responses to the questioner.)
\n\n\nWhy [is the project called] \u201cRadar\u201d?
\n
As noted in the Reddit thread by others, \u201cRadar\u201d is a sound-alike from the ADR acronym. (An early version of the ADR paper was titled Request-Action-Domain-Response, the acronym for which lends itself even more to \u201cRadar\u201d, and I had that in mind too.)
\n\n\nwhy use classes at all? If most of your classes contain a single __invoke method, could they not just be substituted with namespaced functions?
\n
The questioner was answered quite thoroughly on Twitter. I will add only that there\u2019s nothing about ADR that says you must use classes. If you can implement ADR using all functions all the time, go for it. ADR is a pattern, not an implementation; Radar is an implementation, not a pattern.
\nFinally, we have this very good criticism referring to the middleware implementation:
\n\n\nPassing arguments by reference will confuse users.
\n
Variations on this theme came up elsewhere as well. As a result, I have re-worked the middleware implementation completely.
\nPreviously, Radar used a \u201cfilter\u201d style of middleware, where an iterator calls each middleware handler in turn at different points in the execution path. This is the style used by Slim 2 and Silex, and works well with globally mutable request and response objects.
\nHowever, PSR-7 requests and response are immutable. I have not previously used immutables very much, and I tried to subvert the immutability by allowing middleware to use reference parameters. The references would make the request and response objects appear globally mutable, even though the objects were in fact immutable.
\nThe critics who noted that this was potentially confusing, as well as a subversion of the immutable intent, turned out to be worth listening to. I experimented a bit with a wrapper-style (or chain-style) of middleware, and I\u2019m much happier with it.
\nIn the new implementation, each middleware calls the next one in turn, instead of an external iterator looping over them. (There is a Dispatcher object that \u201cholds\u201d the queue of handlers, and that it what gets passed to each handler for its $next call.) I got the idea from reading MWOP\u2019s Conduit code, although this is greatly pared down from that. You can read more about the new implementation here.
Read the Reddit discussion about this post here.
\n" }