Resource Resolvers

Resource Resolvers are a way to resolve request attributes into their "model equivalent".
They are very similar to Param Converters.

They are, however far more flexible and powerful.

You can also think of them as the form does: Request transports the "client" data, and are transformed to "model" data via transformers. Same here, but for an url.

You can use any service of the DIC to transform a requets attribute into something else.
You can also inject these services directly as a method argument ( à la $request).

Configuration is done through a special request attribute: _resources.
Any request that contains this attribute will be resolved.

Usage (via conventional routing loader):

App:BlogPost:deactivate:
    pattern: "/{id}"
    requirements: { _method: "PATCH" }
    defaults:
        "_resources":
            "blogPost":  {service: "app.entity.blog_post_repository", method: "fndIfMine", arguments: [name: "id"]}
          

the above configuration is equivalent to:

<?php

$request->attributes->set(
    'blogPost', 
    $container->get('app.entity.blog_post_repository')->findIfMine(
       $request->attributes->get('id')
    )
);

Right now, every controller (here f.e BlogPostController::deactivateAction) that has a $blogPost argument, will have a BlogPost instance:

<?php

function deactivateAction(BlogPost $blogPost) {}

Lazy resolving

Only methods that define an argument with a concordant name will be resolved.

Optional values

If an argument is marked as optional (f.e: function deactivateAction(BlogPost $blogPost = null) {},
Then its resolving won't throw a 404 exception.

Oherwise, an exception is thrown.

Examples

The yaml is to place into the defaults key of the route.

_resources: { session: { service: service_container, method: get, arguments: [value: session ] } }

results in

<?php

$request->attributes->set('session', $container->get('service_container')->get('session'));