I want to ask first, is the performance gain noticeable?
On Fri, Nov 21, 2008 at 2:16 PM, Olivier Poitrey <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I've used the new and easy to extend symfony 1.2 routing API to write
> some extensions to the routing parsing, so we can have more control
> over its flow. Some projets tends to have very big routing.yml
> configuration files, and any trick that would prevent from having to
> sequentially test each routes can significantly improve performance.
>
> In this regard, I've added two flow control sfRoute children:
> sfJumpRoute and sfGotoRoute. The first one allows to skip the n next
> routes if it's pattern match, and the latter allows to jump to a named
> route and to continue parsing.
>
> Here are some usage example:
>
> my_jump_route:
> url: !^/prefix
> class: sfJumpRoute
> options: { jump: 2 }
>
> my_goto_route:
> url: ^/prefix
> class: sfGotoRoute
> options: { route: route_name }
>
>
> sfPatternSubRouting is a sfRouteCollection (yes, the name doesn't tell
> it) allowing to group some routes together, and to ensure they will be
> skipped if a certain pattern doesn't match. This is particularly
> useful when you have, lets say, 10 routes on the same subjet, with all
> routes starting with the same prefix for instance. You know that if
> the parsed URL have this prefix, it's useless to test each of them one
> after the other, it's better to skip the whole group at once.
> Additionally, you can choose not to store those grouped routes in the
> main routing.yml configuration file but to store them in a separate
> file for a better organization.
>
> Here are two examples, one with embeded routes and another with routes
> stored in another file:
>
> my_subrouting_embed:
> class: sfPatternSubRouting
> options:
> pattern: ^/prefix/
> routes:
> subroute1:
> url: /prefix/:foo
> ...
>
> subroute2:
> url: /prefix/:bar
> ...
>
> my_subrouting_external:
> class: sfPatternSubRouting
> options:
> pattern: ^/prefix/
> file: routing/prefix.yml
>
>
> Last but not least, I've created a special route able to alter the
> parsed URL seen by next routes during parsing. This is useful for
> migrations or evolution of your routing, when you want old URLs to
> continue to work without having to duplicate routes or use mod_rewrite
> redirections.
>
> Here is a simple usage example:
>
> rewriteroute:
> url: ^/foobar(/.*)
> class: sfRewriteRoute
> options: { replacement: /barfoo/$1 }
>
> If you have more than on rewriting to perform, instead of adding x
> routes, sfRewriteRoute supports a kind of batch rewriting:
>
> rewriteroute:
> class: sfRewriteRoute
> options:
> rewrites:
> - [^/foobar, /barfoo]
> - [^/bazbar, /bazbar]
> - [.html$, ~]
> - [^/rss(/.*), $1.rss]
>
>
> For each of these enhancements, I've created a trac ticket:
>
> http://trac.symfony-project.org/ticket/5005 (sfJumpRoute +
> sfPatternSubRouting)
> http://trac.symfony-project.org/ticket/5013 (sfGotoRoute)
> http://trac.symfony-project.org/ticket/5011 (sfRewriteRoute)
>
> I'm interested to hear what you think about those additions, and if
> they would have their place in the sf core.
>
> Please find patches attached to this email (git format, sorry).
>
>
> >
>
>
>
>
> Cheers,
>
> --
> Olivier Poitrey
>
>
>
>
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
