8000 More Flexible Routing via optional/unordered params. inc.. example. · Issue #3705 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content
More Flexible Routing via optional/unordered params. inc.. example. #3705
Closed
@ghost

Description

The routing in SF2 could do with being more flexible in terms of both the number of optional params included and and the order in which they are found if one or more are missing.

Optional parameters in SF2 routes is implemented as {value} however if a slash follows this you have empty value of null and a url with 2 slashes in it which is not a good looking url.

I am often having to have 2 routes for pages with pagination, one route without the pagination and one with, namely because of the word /page being before the number which looks funky if no value follows it. Example:

blog:
    pattern: /blog
blog_filtered:
    pattern: /blog/page/{page}/month/{month}
blog_view:
    pattern: /blog/{id} # works fine for just an id

Unfortunately, that means if i wanted a filtered blog without the page number i have to have /blog/page//month/3 etc but it would be better if i could have /blog/month/3 and /blog/page/2/month/3 for example. The only way around this now is multiple routes for the same thing:

blog:
    pattern: /blog
blog_filtered_1:
    pattern: /blog/page/{page}
blog_filtered_2:
    pattern: /blog/month/{month}  
blog_filtered_3:
    pattern: /blog/page/{page}/month/{month}
blog_view:
    pattern: /blog/{id} # works fine for just an id

Depending on the number of variables, the variations would increase exponentially to encompass each combination of variables.

Routes would be better if we could group the label with the parameter and make them optional to the degree that we do not need 2 slashes ontop of each other. To emphasise the optionality of a route, we should be able to put them in square brackets (e.g [/optional/{param}] ), like so:

blog:
    pattern: /blog[/page/{page}][/month/{month}]
blog_view:
    pattern: /blog/{id} # works fine for just an id

Which also allowed us to remove an item from the first example, and 3 from the second example. The number of routes we can decrease by grows by the number of the number of combinations we need.

This is all useful for pages with varying degrees of parameters that are optional a user may wish to filter page results by.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0