RFC: ParamConverter changes

[beberlei]

Hello,

before I hack away on a big refactoring of param converters I wanted to ask some feedback on my ideas:

• Introduce names for parameter converters, and allow to explicitly specify a converter (optional, defaults to priority iteration)

  /** @ParamConverter("user", name="doctrine.orm") */
  

• Introduce ParamConverterManagerAware interface to inject param converter manager into converters that recursively resolve params.

• ObjectConverter from my Pull-Request GH-137 would be recursively resolving constructor parameters using param converter.

• Replace ConfigurationInterface typehint with something more explicit in ParamConverter interface

• Decouple configuration from annotations, adding other sources of configuration (PHP, XML, YML)

   class MyController
   {
       static public function loadConverterMetadata($actionName, Arguments $args) { }
   }
  

I think param converters could greatly enhance controller usability and become much more powerful than they are now.

[fabpot]

+1 on my side. If you can do that incrementally, that would be even better.

[beberlei]

Point 1: Named converters are convered in GH-142

[beberlei]

The problem with recursive parameter resolving is the Request object in the apply() method. The way the request is used prevents recursion. However the different types of data (attributes, query, request, raw-content) are so HTTP specific - i wouldn't know how to refactor the code to be Request independent and still allow conversion based on different types of input data.

One way would be each converter having a bitmask that differentiates between attributes (filtered and controlled input size), query and request (arbitrary input arrays) and raw content (xml, json). The ParamConverterManager could then decide which data to inject into a parameter holder that replaces the Request object in the API.

[beberlei]

One use-case I am having in mind with recursive parameter resolving is struct/criteria objects that contain persistent objects:

namespace MyBundle\Criteria;
use MyBundle\Entity\Group;

class UserCriteria
{
    private $group;

    public function __construct(Group $group = null)
    {
        $this->group = $group;
    }
}

class UserController
{
    public function listAction(UserCriteria $criteria)
    {
    }
}

Currently I can only do this by passing the $groupId into the UserCriteria instead of the actual Group.

[szymach]

Hello, I have a question regarding your point Decouple configuration from annotations, adding other sources of configuration (PHP, XML, YML). Is this still a thing? I really dislike using annotations and since I use YAML for routing in every project, I have to split the configuration between controller classes and YAML files.