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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
codeconsortium opened this issue Mar 27, 2012 · 12 comments
Closed

More Flexible Routing via optional/unordered params. inc.. example. #3705

codeconsortium opened this issue Mar 27, 2012 · 12 comments
Labels
Feature Routing

Comments

@codeconsortium
Copy link

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.
@khepin
Copy link
Contributor
khepin commented Mar 27, 2012

Isn't that what query strings are for?

@codeconsortium
Copy link
Author

khepin, please clarify what your referring to? Do you have a link or a doc reference please?

@khepin
Copy link
Contributor
khepin commented Mar 27, 2012

http://en.wikipedia.org/wiki/Query_string because it seems you're really trying
to do this:

/blog?page=2&month=6
/blog/post/134

@codeconsortium
Copy link
Author

@khepin yeah, sorry i thought you meant SF2 supported that in the proper route format, i don't like the whole ?page=2&month=6 aspect of it, thats very old school these days.

It would definitely be inconsistent with what the rest of the site has. I feel this kind of flexibility is essential to many modern web apps, and i don't think i am the only one who would like to see this supported as i see other people asking similar questions on the IRC room.

Thought just to clarify when i said unordered, i mean if an optional param is missing, then the next param moves one to the left in order to form a proper route match.

@codeconsortium
Copy link
Author

I have an idea for how this could work, if a Route object had its pattern as an array instead of a string, the SF2 route compiler could convert the route with optional params into multiple patterns, that way they all can match, while still appearing as a single route. The major benefit being that you would not have to change much in the route pattern matching algorithm other than match for each pattern in the array. And being cached would have little impact on performance of the SF2 router. It could be a 2.2 release feature.

@Seldaek
Copy link
Member
Seldaek commented Mar 28, 2012

@codeconsortium it's not very old school. It's how URLs are supposed to be. There is a resource (/blog or /blog/posts/123) and then there are parameters/filters to change the way this resource is displayed, those are just fine in the query string. Paging and such do not belong in the resource URL. There is a middle ground between index.php?<3billion parameters> and /rewrite/everything/and/3/param/4/302/445930.

@codeconsortium
Copy link
Author

@Seldaek to be more precise, its not very Web 2.0 then. Most modern frameworks promote the feature of friendlier urls vs query strings and it seems like a regression to my to go back to QS. The possible solution i provided above though could work by the route containing the pattern as an array of compiled combinations. I guess this is done during the cache warming process. That way a route can match various parameters according to the compiled list of patterns. Just a thought, its one of the big things about SF2 that so much is cached to optimise performance. It would take out the complexity of trying to test overly complex patterns at runtime.

@Seldaek
Copy link
Member
Seldaek commented Mar 28, 2012

It's not about Web 2.0 or not, most older "modern" frameworks promoted this because they misunderstood it, because RewriteRules were the new cool thing to have and abuse, but the modern modern frameworks do not promote this because it does not make sense in terms of HTTP / REST URL design.

@Tobion
Copy link
Contributor
Tobion commented Mar 28, 2012

Agree with @Seldaek

@mvrhov
Copy link
mvrhov commented Mar 28, 2012

I didn't want to say you are doing it wrong and that what you are trying to achieve would be better done via qs.
Here is some interesting reading about api design which IMHO should also be applied to regular website uri design.

@stephpy
Copy link
Contributor
stephpy commented Mar 28, 2012

Agree with @Seldaek too,
If you want to have same comportment as sf1 routing had (:module/:action/:parameter1_name/:parameter_value1/etc ...), you can override Routing, but i'm not sure it's a good idea.

@Tobion Tobion mentioned this issue Apr 26, 2012
Closed
@fabpot
Copy link
Member
fabpot commented Jul 11, 2012

Closing this issue because, besides the philosophical discussion about paths vs query strings, what is proposed would be very difficult to implement without having many non-intuitive behaviors and it would introduce easy to miss colliding routes.

@fabpot fabpot closed this as completed Jul 11, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Feature Routing
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@fabpot @Seldaek @stephpy @mvrhov @khepin @Tobion
0