FileLocatorInterface used in typehint instead of FileLocator
[Routing] allow disabling the requirements check on URL generation
[Routing] added test for disabled requirements check
extended phpdoc of ConfigurableRequirementsInterface
merged branch Tobion/requirementscheck (PR #5187)

Commits
-------

3363832 extended phpdoc of ConfigurableRequirementsInterface
5f64503 [Routing] added test for disabled requirements check
4225869 [Routing] allow disabling the requirements check on URL generation

Discussion
----------

[Routing] allow disabling the requirements check on URL generation

This adds the possibility to disable the requirements check (`strict_requirements = null`) on URL generation.

To sum up, here the possibilities:
- `strict_requirements = true`: throw exception for mismatching requirements (most useful in development environment).
- `strict_requirements = false`: don't throw exception but return null as URL for mismatching requirements and log it (useful when you cannot control all params because they come from third party libs or something but don't want to have a 404 in production environment. it logs the mismatch so you can review it).
- `strict_requirements = null`: Return the URL with the given parameters without checking the requirements at all. When generating an URL you should either trust your params or you validated them beforehand because otherwise it would break your link anyway (just as with strict_requirements=false). So in production environment you should know that params allways pass the requirements. Thus you could disable the check on each URL generation for performance reasons. If you have 300 links on a page and each URL at least one param you safe 300 unneeded `preg_match` calls. I tested the performance in one of my projects. The rendering time of a single template that contains ~300 links with several params was reduced from avg. 46ms to avg. 42ms. That are 8.7% reduction in the twig layer where the links are created on each request. So this option combines the improved usability of strict_requirements=false with an additional increased performance.

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

by fabpot at 2012-08-30T13:40:38Z

Can you put the comment about all the possibilities you have mentioned here in the phpdoc for future reference? Thanks.

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

by Tobion at 2012-08-30T13:49:25Z

In `ConfigurableRequirementsInterface` or which phpdoc would you like to have it? Because `ConfigurableRequirementsInterface` already has it explained. But I can extend its description if thats what you mean.

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

by fabpot at 2012-08-30T13:50:40Z

The comment in the PR is more explicit and more detailed than the one in the interface. So, yes, basically, it would be great if you can move all the information in the interface phpdoc.

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

by Tobion at 2012-08-30T14:35:59Z

Done.
[Routing] added route compile check to identify a default value of a required variable that does not match the requirement
merged branch janmarek/patch-1 (PR #5202)

Commits
-------

890aea2 FileLocatorInterface used in typehint instead of FileLocator

Discussion
----------

FileLocatorInterface used in typehint instead of FileLocator

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

by stof at 2012-08-30T22:09:39Z

@fabpot this makes sense (and it is BC)

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

by mvrhov at 2012-08-31T08:34:17Z

What's wrong with Interface hint? I always hint interface when available as this means that I can inject whatever class implementing that interface.
merged branch Tobion/uselessparamdefaults (PR #5400)

Commits
-------

cb7e3f5 [Routing] added route compile check to identify a default value of a required variable that does not match the requirement

Discussion
----------

[Routing] added route compile check to identify a bad default value

BC break: yes but only for strange route definitions

See the exception message in code for the reasoning.

An exception is thrown for a __required__ variable that __has a default__ that __doesn't match__ the requirement.
So optional variables can of course still have a default that don't meet the requirement, which is useful.
This helps to identify useless route definitions at compile time instead of when generating or matching a URL.
Removed the unnecessary file include

As of Doctrine 2.2, the ORM annotations can be found by the autoloader
directly.
merged branch stof/fix_testsuite (PR #5403)

Commits
-------

7ef6295 Removed the unnecessary file include

Discussion
----------

Removed the unnecessary file include

As of Doctrine 2.2, the ORM annotations can be found by the autoloader directly.

This will also avoid breaking the testsuite in case the dev deps have not been installed as the ORM would not be available in this case (the tests relying on the ORM should already be skipped when it is not available). See #5402