[ParamConverter] Add support for named param converters. They preceed the iteration and make conversion much faster. Add existing converters as "doctrine.orm" and "datetime".
Add documentation on named converters
Fix a bug and a comment position
Refactor AddParamConverterPass loop over tags.
Allow to disable priority registration with priority="false" attribute. Documentation of registration via DIC
Fix bug introduced with CompilerPass refactoring
0 == "false" is true, so we rather check for ===
merged branch beberlei/NamedParamConverters (PR #142)

Commits
-------

6efdeb0 0 == "false" is true, so we rather check for ===
a719ab4 Fix bug introduced with CompilerPass refactoring
85d7c3f Allow to disable priority registration with priority="false" attribute. Documentation of registration via DIC
349ad35 Refactor AddParamConverterPass loop over tags.
de202e4 Fix a bug and a comment position
55753d1 Add documentation on named converters
2ed098d [ParamConverter] Add support for named param converters. They preceed the iteration and make conversion much faster. Add existing converters as "doctrine.orm" and "datetime".

Discussion
----------

[ParamConverter] Add support for named param converters.

Named parameter converters will allow specific choice which param converter is chosen.

* avoid the iterations over many converters
* pick specific converters that otherwise need to be invoked at very late priorities for security reasons.
* It also makes the conversion more explicit, which could take away developer fears not understanding whats happening.
* Cases with different inputs (Query, Request, Raw-Data) might make explicit converter choice necessary.

Fixes GH-116

One open question with this patch is that now every converter automatically has a priority and not a name. You cannot give a converter no priority and only make it available via name. I am thinking to change this to allow registration with priority, name and with both.

* A BC solution would need to introduce <tag name="request.param_converter" priority="false" /> which needs special handling in the CompilerPAss.
* A non BC solution would change every converter without a priority attribute in the DIC tag without priority.

What do you prefer?

---------------------------------------------------------------------------

by beberlei at 2012-07-25T21:38:41Z

docs are missing.

---------------------------------------------------------------------------

by beberlei at 2012-07-25T21:44:33Z

docs are here now

---------------------------------------------------------------------------

by beberlei at 2012-07-25T21:54:20Z

This PR would close GH-116

---------------------------------------------------------------------------

by fabpot at 2012-07-26T06:20:45Z

About the question you have about priorities and names. A converter without a priority would have to be explicitly used via the annotation and the name provided, right? No automatic conversion would ever happen with such a converter?

Anyway, if it does not make the code more complex, I would prefer to have a BC solution, especially because this would be managed in the compiler pass.

---------------------------------------------------------------------------

by beberlei at 2012-07-26T06:47:28Z

Ok i updated it the BC way. Its not a complex solution, just one simple if condition. I added a documentation for DIC registration by tag as well now.

I haven't tested this code yet, i will check in some minutes at my work project and then give a +1/-1 on this PR.

---------------------------------------------------------------------------

by beberlei at 2012-07-26T09:52:50Z

Ok i "functionally" tested this in my application and it works after those two last fixes. You can use named converters and or priority based and the compiler pass works. Actual functionality is tested by the unitt-tests in ParamConverterManagerTest.php and works as advertised.