RFC: Future of Routing & MVC in Flow

Creating Neos & Flow
5

For the record:

@mficzel, @christianm and me discussed this again at our last code sprint and Martin is about to rework the PR at the moment.

In the meantime I had another idea how to support arbitrary invokable classes as controller in a less intrusive way:

Maybe we can keep everything as is, but allow controllerName to be a fully qualified class, too.

This would basically mean, that the two following routes represent the same action:

{
  "uriPattern": "foo/bar/{dynamic}",
  "defaults": {
    "@package":  "Some.Package",
    "@controller": "Foo",
    "@action": "detail"
  }
}

{
  "uriPattern": "foo/bar/{dynamic}",
  "defaults": {
    "@controller": "Some\Package\Controller\FooController",
    "@action": "detail"
  }
}

But it would allow for specifying any other invokable class (which I consider a very important feature and would love to have it for Neos 9):

{
  "uriPattern": "foo/bar/{dynamic}",
  "defaults": {
    "@controller": "Some\Package\HttpHandler"
  }
}

That way we could still use all the URI building infrastructure that we already have, e.g.:

$uri = $this->uriBuilder->uriFor(controllerName: HttpHandler::class);

As a result…:

  • @action and @package would be optional as long as the controllerName is a FQ class name (also in the ActionRequest and in UriBuilder::uriFor())
  • ActionRequest::getControllerObjectName() would be the same as ActionRequest::getControllerName() in those cases
  • While dispatching we could ignore the @action route value – the corresponding controller could evaluate it (and our default ActionController would like today)

I see that this makes a few parts a bit less explicit because there would be more runtime constraints. But – without having thoroughly thought it through yet(!) – it would be worth the change.

What do you think?

3 Likes