So why do you want to prevent having another Dispatcher with a RequestMapper? Say I want to handle failed mapping attempts at a FailedRequestMapper. I would have my RequestMapper return one wrapped in a Dispatcher (which equals your FC) to use it. Perhaps the associated jargon is throwing everyone off, so I'll just demonstrate with a bit of code.
Originally Posted by arborint
class MyRequestMapper implements IRequestMapper
public function mapRequest(Request $request)
return new Dispatcher(new FailedRequestMapper);
return new $action_class;
class Dispatcher implements IHandler
public function execute(Request $request, Response $response)
* On failure, the Dispatcher that works as FrontController receives another Dispatcher
$handler = $this->mapper->mapRequest($request);
* This Dispatcher is executed, resulting in mapping the request again - this time by a
* FailedRequestMapper that knows how to return a, say, 404 error action
if($handler instanceof IHandler)
In my mind we'd need to distinct a Dispatcher and Controller from eachother. For the purposes of our skeleton a Dispatcher could be a Controller that executes based on a RequestMapper, whereas a plain Controller does something entirely else - which could be dispatching to an Action/Command based on what's already in the Request.
I don't think you are going to find another Controller with a constructor that takes a Mapper and dispatches Commands that take request and response as parameters. That is a Front Controller. The fact that it is so simple is deceiving, but it is also highly specialzed.
I agree. I already changed it to $handler some time ago, as per your previous suggestion.
Originally Posted by 33degrees