Hi all
I get the point of Symfony's routes and the solution with using
several routes to match several pattern ( cat1/cat2/cat3 etc... ) but
for me i still think we should have something like customizable routes
in the core ( or possible to extend ).
The reason is, for now it's possible for Symfony to handle url like /
articles/{culture}/{year}/{title}.{_format} , and /articles/{title}.
{_format} using 2 routes, but, for example, if we want to handle both
URL like {culture}/articles/content and /articles/content ( the
{culture} is optional, if missing we will get from session, ip etc )
then the current routes logic will have limit. Moreover, we will have
to add several routes for each of our controller if we want to add the
{culture} like product/{culture}, category/{culture} etc... while if
we have customizable routes, we can check for the first parameter in
URL, see if it's a country code, then set the session and strip this
before process further, and if we have new controller we don't have to
pay attention to its country code in routes. For now we have a work
around on this by extend the HttpFoundation/Request but i am not sure
if this a good idea to extend the core like that.
I agree that with this approach, the routes is not predictable, but we
should be able to control the result imo.
Let me know what you think...
On Feb 27, 4:45 am, [email protected] wrote:
> Yep, I agree, it's not a must on a core and could be exported as a
> separate custom route compiler.
> I did a pull request though as it was really easy fix. Support for
> optional placeholders already exists, however only the ones that were
> in the end were interpreted as optional.
>
> https://github.com/symfony/symfony/pull/112
> --
> Aurelijus Valeiša
>
>
>
>
>
>
>
> On Sat, Feb 26, 2011 at 1:10 AM, ryan weaver <[email protected]> wrote:
> > That *is* how I've solved this in the past. So, it's definitely not
> > necessary, but having 4 different routes for your potentially 4-level deep
> > category URL structure ({cat1}, /{cat1}/{cat2}, ...) feels dirty. When
> > generating URLs for those routes, you also need some extra logic to figure
> > out the "level" of the category so that you know the route name.
>
> > But yea, multiple routes still works and we've git bigger problems to solve.
> > Still, it seems like maybe a nice thing to have, even if it were somehow
> > rolled into a non-core bundle. And if someone is volunteering to code it...
>
> > @weaverryan
>
> > On Feb 25, 2011 4:56 PM, "Benjamin Eberlei" <[email protected]> wrote:
> >> Sorry, but there is an obvious solution that is more explicit: Use two
> >> routes!
>
> >> On Fri, 25 Feb 2011 12:30:11 -0600
> >> ryan weaver <[email protected]> wrote:
>
> >>> If you think you have a good handle on it and want to work on it, then I
> >>> say
> >>> try it out. Two words of direction:
>
> >>> * the feature cannot affect or obfuscate the currently functionality. In
> >>> documentation, it would be explained as an extra, advanced thing to do.
>
> >>> * you must have good test cases in the work
>
> >>> If anyone can think of why this is a bad or unnecessary idea, speak up. I
> >>> tend to think most ideas are good... to a fault :)
>
> >>> @weaverryan
> >>> On Feb 25, 2011 12:22 PM, <[email protected]> wrote:
>
> >>> --
> >>> If you want to report a vulnerability issue on symfony, please send it to
> >>> security at symfony-project.com
>
> >>> You received this message because you are subscribed to the Google
> >>> Groups "symfony developers" group.
> >>> To post to this group, send email to [email protected]
> >>> To unsubscribe from this group, send email to
> >>> [email protected]
> >>> For more options, visit this group at
> >>>http://groups.google.com/group/symfony-devs?hl=en
>
> >> --
> >> If you want to report a vulnerability issue on symfony, please send it to
> >> security at symfony-project.com
>
> >> You received this message because you are subscribed to the Google
> >> Groups "symfony developers" group.
> >> To post to this group, send email to [email protected]
> >> To unsubscribe from this group, send email to
> >> [email protected]
> >> For more options, visit this group at
> >>http://groups.google.com/group/symfony-devs?hl=en
>
> > --
> > If you want to report a vulnerability issue on symfony, please send it to
> > security at symfony-project.com
>
> > You received this message because you are subscribed to the Google
> > Groups "symfony developers" group.
> > To post to this group, send email to [email protected]
> > To unsubscribe from this group, send email to
> > [email protected]
> > For more options, visit this group at
> >http://groups.google.com/group/symfony-devs?hl=en
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
