|
15 | 15 | * ConfigurableRequirementsInterface must be implemented by URL generators that |
16 | 16 | * can be configured whether an exception should be generated when the parameters |
17 | 17 | * do not match the requirements. It is also possible to disable the requirements |
18 | | - * check for URL generation completely to improve performance when you know that |
19 | | - * the parameters meet the requirements anyway (because they are from a trusted |
20 | | - * source or you validated them beforehand which should be the case in production |
21 | | - * environment as it would otherwise break your site). |
| 18 | + * check for URL generation completely. |
| 19 | + * |
| 20 | + * The possible configurations and use-cases: |
| 21 | + * - setStrictRequirements(true): Throw an exception for mismatching requirements. This |
| 22 | + * is mostly useful in development environment. |
| 23 | + * - setStrictRequirements(false): Don't throw an exception but return null as URL for |
| 24 | + * mismatching requirements and log the problem. Useful when you cannot control all |
| 25 | + * params because they come from third party libs but don't want to have a 404 in |
| 26 | + * production environment. It should log the mismatch so one can review it. |
| 27 | + * - setStrictRequirements(null): Return the URL with the given parameters without |
| 28 | + * checking the requirements at all. When generating an URL you should either trust |
| 29 | + * your params or you validated them beforehand because otherwise it would break your |
| 30 | + * link anyway. So in production environment you should know that params always pass |
| 31 | + * the requirements. Thus this option allows to disable the check on URL generation for |
| 32 | + * performance reasons (saving a preg_match for each requirement every time a URL is |
| 33 | + * generated). |
22 | 34 | * |
23 | 35 | * @author Fabien Potencier <fabien@symfony.com> |
24 | 36 | * @author Tobias Schultze <http://tobion.de> |
|
0 commit comments