@@ -22,8 +22,7 @@ Creating Routes as Attributes
22
22
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
23
23
24
24
PHP attributes allow to define routes next to the code of the
25
- :doc: `controllers </controller >` associated to those routes. Attributes are
26
- native in PHP 8 and higher versions, so you can use them right away.
25
+ :doc: `controllers </controller >` associated to those routes.
27
26
28
27
You need to add a bit of configuration to your project before using them. If your
29
28
project uses :ref: `Symfony Flex <symfony-flex >`, this file is already created for you.
@@ -707,12 +706,6 @@ URL Route Parameters
707
706
matches any uppercase character in any language, ``\p{Greek} `` matches any
708
707
Greek characters, etc.
709
708
710
- .. note ::
711
-
712
- When using regular expressions in route parameters, you can set the ``utf8 ``
713
- route option to ``true `` to make any ``. `` character match any UTF-8
714
- characters instead of just a single byte.
715
-
716
709
If you prefer, requirements can be inlined in each parameter using the syntax
717
710
``{parameter_name<requirements>} ``. This feature makes configuration more
718
711
concise, but it can decrease route readability when requirements are complex:
@@ -997,7 +990,7 @@ controller action. Instead of ``string $slug``, add ``BlogPost $post``::
997
990
{
998
991
// ...
999
992
1000
- #[Route('/blog/{slug}', name: 'blog_show')]
993
+ #[Route('/blog/{slug:post }', name: 'blog_show')]
1001
994
public function show(BlogPost $post): Response
1002
995
{
1003
996
// $post is the object whose slug matches the routing parameter
@@ -1011,9 +1004,37 @@ this case), the "param converter" makes a database request to find the object
1011
1004
using the request parameters (``slug `` in this case). If no object is found,
1012
1005
Symfony generates a 404 response automatically.
1013
1006
1007
+ The ``{slug:post} `` syntax maps the route parameter named ``slug `` to the controller
1008
+ argument named ``$blog ``. It also hints the "param converter" to lookup by slug
1009
+ when loading the corresponding ``BlogPost `` object from the database.
1010
+
1011
+ .. versionadded :: 7.1
1012
+
1013
+ Route parameter mapping was introduced in Symfony 7.1.
1014
+
1015
+ When more than one entity needs to be derived from route parameters, collisions can happen.
1016
+ In the following example, the route tries to define two mappings: one to load an author by
1017
+ name, two to load a category by name. But this is not allowed because from the side of the
1018
+ route definition, this declares a parameter named "name" twice::
1019
+
1020
+ #[Route('/search-book/{name:author}/{name:category}')]
1021
+
1022
+ Such routes should instead be defined using the following syntax::
1023
+
1024
+ #[Route('/search-book/{authorName:author.name}/{categoryName:category.name}')]
1025
+
1026
+ This way, the route parameter names are unique (``authorName `` and ``categoryName ``) and
1027
+ the "param converter" can correctly map them to controller arguments (``$author `` and
1028
+ ``$category ``), loading them both by their name.
1029
+
1030
+ .. versionadded :: 7.3
1031
+
1032
+ This more advanced style of route parameter mapping was introduced in Symfony 7.3.
1033
+
1034
+ More advanced mappings can be achieved using the ``#[MapEntity] `` attribute.
1014
1035
Check out the :ref: `Doctrine param conversion documentation <doctrine-entity-value-resolver >`
1015
- to learn about the `` #[MapEntity] `` attribute that can be used to customize the
1016
- database queries used to fetch the object from the route parameter.
1036
+ to learn how to customize the database queries used to fetch the object from the route
1037
+ parameter.
1017
1038
1018
1039
Backed Enum Parameters
1019
1040
~~~~~~~~~~~~~~~~~~~~~~
0 commit comments