> Anyway, the rules are processed in order, so you should be able to include a > rule mapping static to static, and then include the /s$anything rule (which > won't be matched to "static" because the static rule will already have > matched).
That’s actually what I ended up doing, but it isn’t something you can rely on in a big project… > In some cases, $anything isn't powerful enough, and you need to use regular > expressions. I was hoping there would be an alternative, but I guess regular expressions are indeed the only option to do things properly. > Le 25 févr. 2015 à 13:03, Anthony <[email protected]> a écrit : > > In some cases, $anything isn't powerful enough, and you need to use regular > expressions. > > Anyway, the rules are processed in order, so you should be able to include a > rule mapping static to static, and then include the /s$anything rule (which > won't be matched to "static" because the static rule will already have > matched). > > Anthony > > On Wednesday, February 25, 2015 at 6:18:02 AM UTC-5, Louis Amon wrote: > I'm opening this thread to discuss pattern-based routing and especially the > handling of args and vars in an incoming URL. > > > Based on the doc, you can use a simplified syntax in pattern-based routes to > avoid struggling with regular expressions: > ('/new_name/$anything', '/app/controller/function$anything') > If you do so however, the URL /new_name/args would be reachable but /new_name > wouldn't and neither would /new_name?this=that. > > One solution I found to this problem is to write instead: > ('/s$anything', '/myapp/default/search$anything') > (notice there is no / before the $) > > I changed new_name to s in order to illustrate another issue : if you use > $anything like I just did, you might have conflicts between URLs depending on > where in the list (routes_in) your put this specific rule. > > For instance, routing /static would be problematic with a /s$anything rule. > > > In fact, what you really need to route is much less than /s$anything. As far > as I can see there are 4 cases: > 1. /s > 2. /s?vars > 3. /s/args > 4. /s/args?vars > > I guess writing explicity these 4 rules would do the trick much better than > /s$anything, thus avoiding the conflict with /static... but it could also > become very bulky if you have to write 4 rules for each URL. > > > Is there a clean way to do this using the pattern-based system ? > > > -- > Resources: > - http://web2py.com <http://web2py.com/> > - http://web2py.com/book <http://web2py.com/book> (Documentation) > - http://github.com/web2py/web2py <http://github.com/web2py/web2py> (Source > code) > - https://code.google.com/p/web2py/issues/list > <https://code.google.com/p/web2py/issues/list> (Report Issues) > --- > You received this message because you are subscribed to a topic in the Google > Groups "web2py-users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/web2py/sMPkRPjZWrg/unsubscribe > <https://groups.google.com/d/topic/web2py/sMPkRPjZWrg/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to > [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
