On Jan 11, 2011, at 2:39 PM, Wikus van de Merwe wrote:
> To visualise that better let me specify some examples from my own routes
> which are already covered:
> (".*:/favicon.ico", "/init/static/favicon.ico") - covered by default
> (root_static key)
> (".*:/robots.txt", "/init/static/robots.txt") - covered by default
> (root_static key)
> ("/", "/init/default/index") - covert by default (default_controller and
> default_function keys)
> ("/(.+)", r"/init/\1") - covered by default (default_application key)
>
> Now a few cases of url shortening that I'm using in old routes that maybe are
> worth considering in the new one:
> 1) ("/(%s)" % "|".join(DEFAULTS), r"/init/default/\1") - DEFAULTS is the
> list of functions in default controller (I want to skip the default
> controller name in URL)
> 2) ("/f1/(.+)", r"/init/default/f2/\1") - skipping the controller and
> mapping to a function in the default one (it can be turn into example 1 if f1
> == f2)
That's handled, but from a different angle. Instead of listing the functions in
the default controller, the new router lists the controllers in the application
(partly because it's an easy list to generate automatically, and partly because
the function list tends to change more often).
In the normal case, we have a list of all apps, and a list of all controllers
in each app, with the lists generated automatically from the file system.
Besides dropping the default application, we drop the default controller
whenever it can be done unambiguously, so a URL like (say) /init/default/fcn is
shortened to /fcn whenever we know that 'fcn' can't be mistaken for a
controller or application. If it *does* collide with one of those, then we turn
the controller name back on.
Example: suppose you have a function /init/default/init. This gets shortened to
/default/init, which is unambiguous.
A side note: a consequence of the algorithm is that a URL that isn't shortened,
or is less than completely shortened, is always acceptable. In particular, the
full URL is always OK.
> 3) ("/label", "/init/default/func/arg1/arg2/arg3/arg4") - I want to link
> with a short label to a deep element of the page
We don't do that, though it'd be straightforward to implement, either as a
lookup table or as a more general regex facility.
>
> Other examples that I brought forward before might not be worth considering
> as they are very specific and could be represented differently anyway:
> e.g. /author/smith -> /init/default/author?name=smith
> This is equal to ("/func/(.+)", r"/init/default/func?arg1=\1") and could be
> ("/func/(.+)", r"/init/default/func/\1") which is the same as example 1.
Not supported, but if I added a regex capability (as above), it could work.
BTW, this rewrite has problems in the legacy regex system because validity
checking is fairly strict for args. So for example:
/author/Pétain
would be rejected, I think. That makes moving elements from the path to the
query string somewhat less desirable than it might otherwise be. In the new
router, you can relax the validity checking of the path elements, though of
course you'd want to check them at the app level depending on what they're used
for.
>
> One last question, as this is not entirely clear for me. Can I use the new
> routes to point to my app-specific routes defined with old routes regex
> syntax? What about something like autoroutes routes.conf syntax? Wouldn't
> that be useful to benefit from new routes and still have regex (although
> simplified to local app-specific paths) as last resort?
Not supported.
You can have app-specific new-style routes, either in the base routes.py or the
app-specific routes.py. But I don't have a way of invoking the old logic when
the new logic is active.
I'd been thinking that a regex option in the new router would be the way to do
it. It occurs to me that I might be able to let you specify on an app-specific
basis, to use the regex system, but it'd be non-trivial to do it, because the
new system uses completely different URL parsing (in part to avoid some of the
parsing restrictions of the old system).
