[Routing][Feature] add ability to mark optional parameters (when having a suffix or more than a single separator) #5424
Comments
|
Btw, FLOW3 has this possibility to enclose optional part: http://flow3.typo3.org/documentation/guide/partiii/routing.html#optional-route-parts Also in ZF2 there are optional segments: http://framework.zend.com/manual/2.0/en/modules/zend.mvc.routing.html#zend-mvc-router-http-segment Both solutions are quite limited and not as powerful as suggested here. |
|
👍 |
|
+1 |
|
"Milestone: 2.2" : does it means it will be in 2.2 or does it means it might be in 2.2 ? |
|
it means "might be", but it won't as 2.2 is in the RC phase now. |
|
I changed it to 2.3 now |
|
Hope it will be included in 2.3, this would allow really nice human-readable urls (and anyone who cares about position in google results will appreciate that!) |
|
👍 from my part. I'm not sure what it means for ApacheDumper though. It shouldn't be a problem I suppose, this is just compiled to regexes right? |
|
Yes, it's just exposing more flexibility and also compiles to regex. |
|
+1 This feature seems usefull ! Does this PR can have a negative impact on performance? |
|
Matching won't have a negative impact on performance. Generating URLs will be a more complex but I don't think it's a big deal. |
|
Our use-case: We are having cities, categories, categories parameters. All of this parameters is optionsl. So we have defined routes: index: /
index_category: /{category_slug}
index_city: {city_slug}.%base_host%
index_city_category: {city_slug}.%base_host%/{category_slug}
index_city_category_parameters: {city_slug}.%base_host%/{category_slug}/{parameters_slug}
# ...And there is madness when we need generate route: {% set routeName = 'index' %}
{% if foo %}
{% set routeName = 'index_foo' %}
{% if bar %}
{% set routeName = 'index_foo_bar' %}
{% endif %}
{% endif %}
{{ path(routeName, {'foo': foo, 'bar': bar}) }} |
|
@Koc the examples you gave only have 1 char seperator and the optional parts start at the end. I don't really see why you need multiple routes for that because that is already support at the moment. So which feature of this suggestion ticket do you need? |
|
we need trailing shash everywhere and for cities we are using SprosProjectBundle:Default:index:
pattern: /
defaults: { _controller: SprosProjectBundle:Default:index }
host: %base_host_metallspros%
SprosProjectBundle:Default:index_category:
path: /{category_slug}/
defaults: { _controller: SprosProjectBundle:Default:index }
host: %host_prefix_metallspros%%base_host_metallspros%
requirements:
category_slug: %category_with_parameters_slug_regex%
SprosProjectBundle:Default:index_subdomain:
pattern: /
defaults: { _controller: SprosProjectBundle:Default:index }
host: "{subdomain}.%base_host_metallspros%"
SprosProjectBundle:Default:index_subdomain_category:
path: /{category_slug}/
defaults: { _controller: SprosProjectBundle:Default:index }
host: "{subdomain}.%base_host_metallspros%"
requirements:
category_slug: %category_with_parameters_slug_regex% |
|
👍 |
|
👍 |
1 similar comment
|
👍 |
|
This would really be nice addition to 2.5 |
|
👍 |
|
👍 |
|
Any news on this PR, is it planned for 3.0? It would be very awesome! |
|
+1 on this issue, I would love to see it in a new Symfony release |
|
Seems like everyone would love this feature, but noone is actually working on implementing this. Am I wrong? |
|
I already started it in #7051 and will try to finish it for 3.0 |
|
@Tobion great, I'll have a look maybe I can help somehow 8-) |
|
it would be nice to issue automate 301 redirect to "most short" url. so, for route /products(-by-{criterion}).html (which would match /products.html with criterion = default or /products-by-price.html with criterion = 'price') when somebody request /products-by-default.html issue 301 redirect to /products.html, so no duplicate content would be generated |
Currently an optional variable (that has a default and can be left out from matching and generating URLs) can only be specified without any text suffix, i.e. at the end of the pattern. This is quite limiting.
@laszlokorte and I propose to add the possibility to mark the optional parts with parentheses/curly brackets.
This can be implemented BC and would allow several new, but common use-cases, e.g.:
Examples:
/products(-by-{criterion}).htmlwould either match/products.htmlwithcriterion = defaultor/products-by-price.htmlwithcriterion = 'price'/products(/{category}(.{_format}))would be equivalent to how we already handle/products/{category}.{_format}with defaults for both variables. It matches/products,/products/shoesand/products/shoes.html. But it does not match/products.html! Compare that to/products((/{category}).{_format})(only brackets changed) where the format would match without category, but the category does not match without the format. So the inner part requires the outer part to match./products(-in-{category})(-by-{criterion}).htmlmatches/products.htmland/products-in-shoes-by-prize.htmland/products-in-shoes.htmland/products-by-prize.html./products(-in-{category1}-and-{category2}).htmlonly matches the optional part when both variables match, so/products-in-shoes-and-suits.htmland/products.html, but not/products-in-shoes.html./products(-by-price).htmlshould either raise exception that there is no variable in it, or treat it as-is (with the parentheses). It must not match both/products.htmland/products-by-prize.html(where you should usually specify 2 routes for it) because there would be no way to decide which URL to generate./products/({category})would match/products/and/products/...whereas without the parentheses it would match/productsand/products/...(see Routes of the form /hello/{name} with an optional parameter at the end don't match as expected #5869)/{product}((-by-{criterion}).{_format})would need a default requirement forproductto be[^/-\.]++(so as seperator both/(standard) and-and.. Pretty hard to compile.Also, it should raise an exception when you specify an optional part explicitly without adding a default for the variable in it.
This feature request is somewhat related to #5129 and also covers #5869 and #10217 and #9981
The text was updated successfully, but these errors were encountered: