On Thursday, February 26, 2015 at 3:35:50 AM UTC-5, Louis Amon wrote:
>
> That’s actually what I ended up doing, but it isn’t something you can rely
>> on in a big project…
>>
>
> Why not?
>
>
> Because you’d have to document very clearly the fact that some specific
> rules need to be organized i
> That’s actually what I ended up doing, but it isn’t something you can rely on
> in a big project…
>
> Why not?
Because you’d have to document very clearly the fact that some specific rules
need to be organized in a precise order among the list.
If you have hundreds of URLs managed in your rou
BTW... just to synchronize ourself, what the book gives as an example is
('/new_name/$anything', '/app/controller/function*/*$anything')
mind the */* part . This is the only safe way to do what people usually
want to "translate", that is the app/c/f part, while leaving args and vars
untouched.
On Wednesday, February 25, 2015 at 7:54:36 AM UTC-5, Louis Amon wrote:
>
> 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
> 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
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$an
6 matches
Mail list logo
